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1.  Introduction [Dasa  &  AFRL] 

1.1  Program  Background 

The  foundation  for  the  Transatlantic  Research  into  Air  Combat  Engagements  (TRACE)  program  was  laid  in 
1992  with  discussions  held  between  Hannes  Ross  of  Daimler  Benz  Aerospace  (Dasa)  and  Don  Gum  of  Air 
Force  Research  Laboratory  (AFRL).  At  that  time  both  Dasa  and  AFRL  were  interested  in  the  development 
of  combat  pilot  aiding  systems.  Both  countries  felt  that  there  was  significant  value  in  conducting 
evaluations  comparing  the  performance  of  the  two  country’s  pilot  aiding  systems;  Integrated  Control  and 
Avionics  for  Air  Superiority  (ICAAS),  developed  by  AFRL,  and  Automated  Maneuvering  Attack  System 
(AMS),  developed  by  Dasa.  Since  both  of  these  systems  were  in  development  at  that  time,  simulation  was 
chosen  as  the  best  approach  to  conduct  comparative  research.  Dasa  had  a  simulation  of  AMS  running  at 
their  facility  near  Munich,  Germany,  and  Air  Force  Research  Laboratory  had  an  ICAAS  simulation  in 
Dayton,  Ohio,  USA.  The  original  thought  was  to  rehost  one  of  these  simulations  at  the  other  facility; 
however,  there  were  many  difficulties  with  that  approach.  Each  simulation  had  been  developed  and  hosted 
on  different  computer  systems.  This  made  rehosting  the  simulations  difficult.  A  significant  amount  of 
manpower  and  equipment  investment  would  have  been  required  to  get  both  simulations  operating  in  the 
same  facility.  There  were  also  significant  security  issues  to  resolve  to  implement  the  approach  due  to  the 
classification,  and  proprietary  nature  of  the  software  code  which  implemented  the  combat  pilot  aiding 
algorithms. 

Although  in  its  infancy,  simulator  networking  was  of  interest  to  both  countries.  Researchers  in  both 
Germany  and  the  US  believed  that  network  simulation  had  the  long-term  potential  to  provide  a  powerful 
means  to  conduct  cooperative  research  and  evaluations.  Dasa  and  AFRL  had  conducted  network 
simulations  within  their  own  country  and  realized  that  there  were  some  significant  performance  issues  which 
needed  to  be  resolved  before  the  network  quality  was  good  enough  to  conduct  comparative  evaluations 
between  AMS  and  ICAAS.  These  issues  were  evaluated  and  it  was  jointly  decided  that  if  the  network 
issues  could  be  satisfactorily  resolved,  that  simulation  networking  would  be  the  best  and  lowest  cost 
approach  for  conducting  the  AMS  and  ICAAS  evaluation.  If  successful,  this  evaluation  would  also  lay  the 
foundation  for  future  cooperative  research  between  the  two  countries. 

Between  1992  and  1995,  there  were  ongoing  discussions  between  the  Dasa  and  AFRL,  and  the  concept  of 
the  Transatlantic  Research  into  Air  Combat  Engagements  (TRACE)  evolved.  An  approach  was  developed 
which  split  the  TRACE  program  into  two  distinct  phases.  Phase  I  was  to  develop,  optimize,  test  and 
evaluate  a  joint  network  simulation.  Phase  II  was  to  use  the  network  to  conduct  the  comparative  evaluation 
between  AMS  and  ICAAS. 

Establishing  the  Memorandum  of  Understanding  (MOU)  to  conduct  the  TRACE  program,  and  funding  the 
program  proved  very  difficult  for  both  the  US  and  Germany.  Requirements  for  establishing  the  program 
agreements  changed  through  the  1992  to  1995  period.  Various  funding  sources  were  identified  and 
subsequently  disappeared.  In  1995,  an  “umbrella”  MOU  between  Germany  and  the  US  to  conduct  joint 
research  was  established.  The  TRACE  program  was  defined  and  Phase  I  of  TRACE  became  ANNEX  3  to 
the  umbrella  MOU  in  November  1995. 

In  retrospect,  dividing  the  program  into  two  phases  was  not  a  good  idea.  It  was  done  to  minimize  risk,  and 
to  simplify  approval  since  Phase  I  was  totally  unclassified  and  did  not  require  special  security  approval. 
Unfortunately,  by  starting  the  program  with  approval  for  only  Phase  I,  the  overall  objective  to  conduct 
comparative  research  between  combat  pilot  aiding  systems  was  not  perceived  by  senior  management;  that 
portion  of  the  program  was  to  have  been  accomplished  in  Phase  II.  This  was  later  to  become  a  significant 
issue  for  funding  and  program  continuation  as  described  in  section  2.1.2. 

Phase  I  of  the  TRACE  program  was  kicked  off  in  November  1995  with  a  joint  meeting  between  Dasa  and 
AFRL  at  Wright-Patterson  Air  Force  Base,  Ohio.  Many  of  the  program  details  were  worked  out  at  that 
meeting.  The  meeting  established  an  excellent  working  relationship  between  the  engineers  and  managers  at 
Dasa  and  AFRL  which  lasted  throughout  the  program.  For  example,  the  idea  for  weekly  Wednesday 
telephone  conversations  was  established.  The  weekly  conversations  served  to  coordinate  the  work  between 
the  two  facilities  throughout  the  program. 
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The  following  indicates  a  brief  summary  of  when  each  task  was  completed: 
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Date 

Event 

Nov  95 

MOA  signed 

Nov  95 

TRACE  kick-off  meeting 

Jul  96 

Initial  US-German  network  connections 

Aug  96 

Start  network/protocol  testing 

Oct  96 

First  US-German  simulation  connections 

Sep  97 

First  US-German  full  simulation  scenarios 

Oct  97 

Start  piloted  tests 

Mar  98 

Phase  I  completion 

1.2  Program  Objectives 

The  TRACE  Phase  I  program  objective  was  to 

1)  perform  United  States  Air  Force  (USAF)  and  German  Ministry  of  Defense  (MOD)  research  in  the  area 
of  long  haul  simulator  network  technology  by  coupling  the  simulation  facilities  of  Air  Force  Research 
Laboratory  (AFRL)  and  Deutsche  Aerospace  (Dasa), 

2)  conduct  simulations  showing  the  technical  capabilities/limitations  for  potential  operational  use  for 
aircrew  training,  and 

3)  establish  the  necessary  conditions  required  for  a  comparison  of  the  combat  pilot  aiding  systems 
developed  by  both  parties. 

Specific  objectives  included  establishing,  optimizing,  testing,  and  evaluation  a  robust  high-fidelity 
simulation  network  between  Dasa  and  AFRL.  Two  different  networks  were  evaluated.  One  was  a  128Kb/s 
commercial  ISDN  telephone  network,  and  the  second  was  a  128  Kb/s  Defense  Simulation  Internet  (DSI) 
connection.  Three  different  protocols  were  evaluated  on  each  of  the  networks; 

1)  the  Distributed  Interactive  Simulation  (DIS), 

2)  the  German  distributed  network  protocol  referred  to  as  “Dasa  protocol”,  and 

3)  DIS-Lite  which  was  an  efficient  version  of  DIS. 

One  objective  was  to  implement  each  of  the  protocols  on  both  networks  and  to  measure  the  performance 
using  the  Simulator  Network  Analysis  Project  (SNAP)  hardware.  A  significant  objective  was  to  implement 
a  high-fidelity  joint  simulation  on  the  optimized  network  which  included  multiple  piloted  highly  dynamic 
fighter  aircraft  with  missiles,  guns,  radar,  etc.,  and  multiple  digital  players. 

The  final  TRACE  Phase  I  objective  was  to  demonstrate  the  ability  of  an  optimized  international  simulation 
network  to  support  joint  training  and  research. 


The  program  objectives  are 

•  Design  and  Implement  a  Transatlantic  Network  Simulation  Architecture  to  Support  Highly  Dynamic 
Vehicles 

•  Evaluate  Alternate  Links  and  Various  Network  Protocols 

•  Thoroughly  Test  and  Characterize  Network  Performance 

•  Show  Technical  Capabilities/Limitations  for  Operational  Use 
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2.  TRACE  Program  Background  &  AFRL] 

2.1  TRACE  Annex 

2.1.1  Verification  of  Completion  of  Each  Task 

In  the  following,  the  verification  of  all  the  main  tasks  in  the  TRACE-program  are  described.  Both  AFRL  and  DASA 
were  working  on  all  tasks  in  cooperation.  For  correct  and  efficient  completion  of  these  tasks,  the  technical  support  of 
each  party  was  indispensable  (i.e.  if  installing  SNAP  or  DASA-Protocol). 

2.1. 1.1  Task  1:  Program  Preparation 

This  Task  was  completed  in  December  1995. 


2.1.1.2  Task  2:  Network  Development  &  Prototyping 

The  network  was  specified  and  a  detailed  schedule  for  the  development  was  drawn  up.  After  procuring  the  required 
hardware  a  critical  design  review  was  performed,  the  link  between  DASA  and  AFRL  was  established  and  tested  via 
both  an  ISDN  and  a  DSI  line. 

The  DASA-,  DIS-  and  additionally  DIS-Lite  protocols  were  implemented  on  the  simulation  systems.  For  the  DASA 
implementation  a  standalone  NIC  was  shipped  to  and  installed  at  AFRL  and  the  interface  adapted  to  that  of  the 
AFRL-simulation.  At  DASA  a  DIS  and  a  DIS-Lite  interface  were  developed  and  tested. 

The  DIS-Protocol  was  adapted  to  cover  TRACE  requirements  and  used  as  the  German/American  air  force  related 
simulation  protocol. 

Later,  the  SNAP  equipment  was  shipped,  installed  at  DASA  and  initial  measurements  were  performed. 

A  voice  communication  link  was  established  first  with  a  special  DIS-Radio  and  later,  because  of  performance 
problems,  via  standard  analog  telephone  line. 

Data  recording  systems  were  developed  and  used  for  theoretical  performance  tests  using  the  DIS-  and  DASA- 
Protocol 

2.1.1.3  Task  3:  Assessment  Simulation  Preparation 

The  AMS  simulation  was  reactivated  and  detailed  plans  were  developed.  The  simulation  models  were  generated  and 
exchanged  between  the  Dasa  and  AFRL  if  necessary.  Existing  aircraft  and  avionics  models  were  improved  and  parts 
of  the  weapons  model,  the  G-dimming  and  G-loc  models  were  exchanged. 

The  simulations  were  networked  both  via  DSI  and  ISDN  links  and  fundamental  tests  were  performed  with  the  first 
versions  of  the  network  interfaces.  Measurements  with  the  SNAP  equipment  and  basic  functionality  tests  of  the  three 
protocols,  the  models  and  the  simulations  were  performed  in  this  phase. 

2.1.1.4  Task  4:  Simulation  Checkout 

Both  the  AFRL  and  the  DASA  simulations  were  checked  out  as  well  as  the  established  network.  For  performance 
reasons  and  the  unreliability  of  the  DSI,  ISDN  was  chosen  for  the  networking  media. 

Flight  tests  were  performed  using  the  test  scenarios  developed  for  the  productions  runs  with  all  three  protocols. 
Technical  problems  that  occurred  during  the  tests  were  corrected. 

2.1.1.5  Task  5:  Assessment  Simulation  Production  Runs 

For  the  productions  runs  5  scenarios  with  increasing  complexity  has  been  developed  to  ensure  the  pilots 
familiarization  as  well  as  the  possibility  for  tactical  training  in  complex  combat  engagements.  For  a  mission  with  a 
common  German- American  force  against  a  force  of  computer  generated  forces,  the  requirements  of  the  TRACE 
program  were  exceeded.  This  new  requirement  called  for  the  DASA  simulation  to  control  6  independent  aircraft 
(with  all  their  missiles). 
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During  the  production  runs,  two  scenarios  with  even  greater  complexity  were  requested  by  the  pilots.  These 
scenarios  were  generated  to  intensify  the  effect  of  training  during  the  joint  missions. 

After  each  run  and  at  the  end  of  each  day,  pilot  debriefings  were  held  with  between  all  pilots  involved  in  the  testing 
and  the  system  engineers.  These  debriefings  resulted  in  some  modifications  to  the  simulations  to  provide  the  best  test 
and  training  effect. 

As  one  result  some  modifications  has  been  done  on  the  simulations  to  ensure  the  highest  possible  test  and  training 
effect.  The  debriefing  was  supported  by  a  local  quick  look  functionality  after  each  session. 

At  the  end  of  this  phase,  two  separate  demonstrations  were  performed  with  both  DASA  and  AFRL  participating 
followed  by  a  final  debriefing.  Finally,  the  pilots  composed  a  pilots  report. 


2.1. 1.6  Task  6:  Analysis  and  Recommendations 

The  collected  data  was  analyzed  with  the  results  and  protocol  recommendations  shown  in  this  final  report  (see 
Chapter  4). 


2.1.2  AFRL  Funding 

The  TRACE  programwarjomtly  funded  by  Germany  and  the  US.  Each  country  agreed  tofundj^esearch  in  its  own 
respective  sinmlation  facility.  The  signed  TRACE  Annex  to  the  MOU  between  Germany  and  theTJS-agreed  to  the 
followin&Jtfnding  profile: 


ICE  Phase  I  FUNDING  ( in  $  M  ) 
PREV 
0 
0 


FY96 

FY97 

FY98 

TOTAL 

.748 

.843 

.950 

2.541 

.993 

1.920 

.860 

3.77i^5> 

The  US  funding  of  the  progranTprocccdod  aTr  this  profile  up  until  I  1^3.  Tne  US  portion  of  the  TRACE  program 
was  reviewed  by  a  high  level  representative  of  DDR&E,  Dr.  Dix,  during  his  March  1997  TARA  review  at  Wright 
Laboratory.  Despite  excellent  Phase  1  results,  Dr.  Dix  was  very  critical  of  the  TRACE  program  because  he  feels  that 
flight  control  funds  should  not  be  spent  on  network  technology  even  if  it  supports  future  flight  control  research. 

Based  on  his  negative  comments,  there  was  a  serious  funding  cut  to  TRACE  Phase  I  in  FY98.  The  Flight  Control 
Division  of  Wright  Laboratory  only  funded  $45K  to  the  TRACE  program  in  FY98.  The  remainder  of  the  funding  for 
personnel,  equipment,  line  rental,  and  facilities  was  made  up  through  other  sources.  In  total,  approximately  $550K  in 
funding  from  all  sources  will  be  expended  by  the  US  during  FY98.  Total  US  funding  for  the  entire  program  will  be 
approximately  $2.1M. 


2.1.3  TRACE  Goals 

By  networking  simulation  facilities  on  opposite  sides  of  the  Atlantic  ocean,  the  TRACE  Program  will  develop  and 
demonstrate  the  technology  necessary  to  conduct  integrated  research  and  training  simulations  involving  diverse 
NATO  aircraft  across  long  distances.  Phase  I  will  define  and  implement  a  network  architecture  using  different 
networks  and  protocols,  such  as  the  Distributed  Interactive  Simulation  (DIS)  and  the  DASA’s  protocols  on  the 
Defense  Simulation  Internet  (DSI)  or  on  a  standard  ISDN  telephone  line.  The  Simulation  Network  Analysis  Project 
(SNAP)  computers  will  measure  the  network  performance  achieved. 

Program  Objectives: 

•  Perform  USAF  and  MOD  research  into  long  haul  simulator  network  technology  by  coupling  the  simulation 
facilities  of  AFRL  and  DASA. 

•  To  conduct  simulations  showing  the  technical  capabilities/limitations  for  potential  operational  use  in  aircrew 
training. 

•  Determine  feasibility  for  developing  a  common  American/German  protocol  optimized  for  Air  Force  applications. 
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2.2  TRACE  SOW 

The  TRACE  Statement  of  Work  (SOW)  established  the  program  organization,  technical  requirements  and  division  of 
responsibilities  for  the  program. 

The  SOW  TRACE  jointly  organized  the  program  between  the  German  Ministry  of  Defense  and  the  United  States  Air 
Force.  Responsibility  for  accomplishment  of  the  program  was  assigned  to  Air  Force  Research  Laboratory's  Control 
Integration  and  Assessment  Branch  located  at  Wright-Patterson  Air  Force  Base,  Dayton,  Ohio  and  Deutsche 
Aerospace  (DASA)  located  in  Munich,  Germany.  The  SOW  enumerated  the  technical  requirements  for  the  project 
through  the  following  Work  Breakdown  Structure: 

TRACE  Phase  I  Work  Breakdown  Structure 

1 .0  Program  preparation 

1 . 1  Coordination  meeting  at  WPAFB 

1.2  Program  planning 

1 .3  Resolve  detailed  networking  issues 

1 .4  Joint  program  discussions 

1 .5  MOU  annex  preparation 

1.6  MOU  signed 

1 .7  DEA  DDL  preparation 

1.8  DEA  DDL  signed 

2.0  Network  development  &  prototyping 

2.1  Establish  &  test  network 

2.1.1  Define  network  specification 

2.1.2  Develop  detailed  networking  plans 

2.1.3  Procure  hardware 

2. 1 .4  Establishment  of  network  link  between  facilities 

2.1.5  Test  link  using  newest  available  DIS  protocol 

2. 1 .6  Test  link  using  DAS A’s  simulation  protocol 

2. 1 .7  Develop  a  common  German/American  air  force  related  simulation  protocol 

2.1.8  SNAP  network  performance  measurement 

2.2  Establish  voice  communication  link 

2.3  Establish  capability  for  data  recording 

2.4  Link  established 

3.0  AMS/ICAAS  simulation  preparation 

3. 1  Reactivate  AMS  Simulation 

3.2  Develop  detailed  AMS/ICAAS  simulation  plans 

3.3  Generate  standardized  simulation  models 

3.3.1  Generic  aircraft  model 

3.3.2  Generic  weapon  model 

3.3.3  Generic  avionics  models 

3.3.4  G-Dimming  and  GLOC  models 

3.7  Fundamental  network  test 
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4.0  Simulation  checkout 

4. 1  Definition  &  realization  of  baseline  functions 

4.2  WPAFB  simulation  checkout 

4.2. 1  Verify  generic  US AF  Fighter 

4.3  DASA  simulation  checkout 

4.3. 1  Verify  baseline  GAF 

4.4  Network  integration  checkout 

4.5  Test  flights 

4.6  Analysis  &  corrective  actions 

4.7  Ready  for  production  runs 

5.0  Evaluation  production  runs 

5.1  Pilot  training 

5.2  Data  collection 

5.2.1  Scenario  1  l  +  1 

5.2.2  Scenario2  1  vs  1 

5.2.3  Scenario3  2  vs  2 

5.2.4  Scenario4  2+2  vs  2+2 

5.2.5  Scenario5  4  vs  2+2 

5.3  Pilot  debriefing 

5.4  Data  quick  look 

5.5  Preliminary  report 

5.6  Demonstration 

5.7  Simulator  and  network  support 

6.0  Analysis  &  recommendations 

6. 1  Data  analysis 

6.2  Protocol  recommendations 

6.3  Final  report 

6.4  Briefing  to  customer 

The  SOW  provided  a  detailed  task  description  and  defined  each  organizations  responsibilities  to  accomplish  the  tasks 
and  sub-tasks.  It  also  included  a  2  year,  3  month  schedule  to  complete  TRACE  Phase  I.  The  SOW  outlined  the 
entire  TRACE  project  into  four  phases. 


2.3  TRACE  Schedule 

Kickoff  Meeting  Nov  95 

Network  Link  Established  Aug  96 

Start  SNAP  Latency  Tests  Oct  96 

Common  Protocol  Developed  Feb  97 

Network  Test  Complete  Apr  97 

Simulations  Linked  Across  Network  Sep  97 

Simulation  Checkout  Complete  Sep  97 

Assessment  Simulation  Runs  Complete  Nov  97 

Analysis  and  Recommendations  Mar  98 
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2.4  TRACE  Personnel 


2.4.1  AFRL/VACD  Personnel 

Name 

Main  Duty 

Additional  Duties 

Lt.  Stephen  Purdy 

TRACE  Program  Manager 

• 

SNAP  Operator 

(AFRL/FIGD  Side) 

• 

VTC  Hardware 

Ron  Ewart 

AFRL/FIGD  Chief  Scientist 

• 

• 

• 

TRACE  Program  Advisor 

Communications  Hardware 

Simulator  Hardware 

Dan  Caudill 

Simulation  &  Executive 
Programmer 

• 

AFRL/FIGD  Pilot  Coordination 

Roger  Wuerfel 

Networking  Programmer 

• 

Expert  on  DIS,  DIS-Lite  Protocols 

Halifax  Contractor 

• 

AFRL/FIGD  SCRAMNet  Code 

• 

NIC  Integration  into  AFRL/FIGD 

Simulation 

• 

VR-Link  Integration  at  AFRL/FIGD  & 
DASA 

Capt.  Ron  Johnston 

Network  Setup 

• 

SNAP  Operator 

(ISDN/DSI/SCRAMNet) 

• 

Communications  Hardware 

Lt.  David  Barnhart 

SNAP  Program  Lead 

• 

Expert  on  DIS,  DIS-Lite  Protocols 

Kevin  Maloney 

Simulation  Programmer 

• 

DASA  Missile  Model  Integration  at 

Halifax  Contractor 

AFRL/FIGD 

Ernie  Payne 

AFRL/FIGD  RADAR  Lead 

• 

DASA  RADAR  Model  Integration  at 

Halifax  Contractor 

AFRL/FIGD 

Lt.  Rob  Subr 

Simulation  Graphics 

• 

VBMS  Programmer/Operator 

Larry  Mutschler 

AFRL/FIGD  Database  Lead 

Don  Gum 

AFRL/FIGD  Branch  Chief 
(retired  January  1997) 

• 

Initiated  TRACE  Program 

Ed  Allen 

SNAP  Operator 
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Main  Duty 


2.4.2  DASA  Personnel 

Name _ 

Dr.  Klaus  Holla 
Florian  GraBel  (Graessel) 

Herbert  Eibl 
Johann  Neuhauser 
Diedrich  Hartung 
Wolfgang  Bader 
DASA  contractor 
Karl  Scalet 
DASA  contractor 
Arthur  Lutzenberger 
Robert  Hoogvliet 
Wolfgang  Ponikwar 
Franz  Sulzberger 


Program  Manager 
Technical  Leader/Manager 


Simulation  Software 
DASA  &  DIS  Protocol 
Simulation  Software 
DASA  NIC 

Networking  (ISDN/DSI) 

Data  Recorder 
DASA  SNAP  Operator 
DIS  Radio 

Simulator  Hardware  (cockpit) 


Additional  Duties 


•  Testpilot 

•  Data  Recorder 

•  Data  Analysis 

•  Testpilot 

•  DASA  NIC 

•  DASA  &  DIS  Protocols 


•  Testpilot 


2.4.3  Other  TRACE-Related  Personnel 


Name _ 

Johann  Pogarell 
Jobst  Frank 
Jerri  Messinger 
Don  Gum 


Main  Duty _ _ _ 

German  MoD 

German  Liaison  at  Wright-Patterson  Air  Force  Base 

International  Programs  Manager  at  Wright-Patterson  Air  Force  Base 

AFRL/VACD  Branch  Chief  that  headed  US  efforts  for  TRACE  (now  retired) 


2.5  AFRL/VACD  Simulation  Facility [AFRL] 


2.5.1  Background/Introduction 

The  AFRL/VACD  simulation  facility  began  initial  operation  in  1979.  The  majority  of  the  research  performed  at  this 
facility  since  its  inception  has  been  flying  qualities  and  flight  control  related.  In  1989,  the  Integrated  Control  and 
Avionics  for  Air  Superiority  (ICAAS)  program  requested  simulation  support  from  within  the  Flight  Control  Division 
and  the  first  in-house,  multi-ship,  air  combat  simulation  was  bom.  The  ICAAS  program  essentially  paid  for  the 
purchase  and  development  of  the  Mission  Simulator  One,  the  Piloted  Combat  Stations,  the  mission  planning  rooms, 
the  main  simulation  control  room,  and  most  of  the  simulation  and  graphics  computers.  These  components  of  the 
facility  are  the  main  assets  that  have  been  utilized  by  the  TRACE  program.  A  description  of  the  majority  of  the  assets 
in  the  AFRL/VACD  facility  are  described  in  the  following  sections. 

2.5.2  AFRL/VACD  Simulators 

The  AFRL/VACD  simulation  facility  contains  three  main  simulator  types:  Mission  Simulator  One  (MS-1),  the  Large 
Amplitude  Multi-Mode  Aerospace  Research  Simulator  (LAMARS),  and  the  Piloted  Combat  Stations.  These 
simulators  and  the  AFRL/VACD  simulation  computers  are  normally  controlled  from  one  of  two  simulation  control 
consoles.  These  simulators,  as  well  as  the  control  consoles  and  simulation  computers,  will  be  described  in  the 
following  sections. 
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2.5.2. 1  Mission  Simulator-One  (MSI) 

The  Mission  Simulator  One  is  a  forty  foot  diameter  dome  simulator  capable  of  up  to  360°  visual  field  of  view  with  or 
without  a  40°  high  resolution  area  of  interest  inset  directly  in  front  of  the  pilot.  The  cockpit  configuration  can  be 
modified  to  satisfy  individual  simulation  requirements  and  the  entire  cockpit  can  be  replaced  with  a  new  cockpit 
design  if  needed.  The  main  capability  provided  by  the  MS-1  is  Air-to-Air  combat  mission  simulations,  although  it 
can  be  used  effectively  for  other  types  of  simulations  as  well.  The  resolution  and  contrast  of  the  visual  scene 
provided  to  the  pilot  make  the  MS-1  least  suited  for  Air-to-Ground  missions  where  visual  identification  of  the  target 
is  necessary.  A  picture  of  the  outside  of  the  MS-1  can  be  seen  in  Fig.  2-1. 


Fig.  2-1  Mission  Simulator  One  (MS-1) 


2.S.2.2  Large  Amplitude  Multi-Mode  Aerospace  Research  Simulation  (LAMARS) 

The  LAMARS  is  a  unique  simulator  that  combines  a  twenty  foot  diameter  dome  cockpit  on  a  30  foot  arm  with  a  5 
DOF  motion  system.  The  range  of  displacement  available  at  the  cockpit  is  +/-10.0  feet  vertically  and  laterally  as  well 
as  an  angular  capability  of  +/-25.00  in  each  of  the  roll,  pitch,  and  yaw  axes.  The  LAMARS  simulator  has  the 
capability  to  generate  instantaneous  load  factors  at  the  pilot  station  of  +/-  3.0  Gs  vertically  and  +/-  1.6  Gs  laterally.  It 
can  also  provide  instantaneous  angular  accelerations  of  +/-400.0,  +/-460.0,  and  +/-200.0  degrees/second2  in  the  pitch, 
roll,  and  yaw  axes,  respectively.  These  features  combined  give  the  LAMARS  outstanding  force  cueing  capability  for 
piloted  simulations.  The  cockpit  is  similar  in  flexibility  to  the  MS-1,  but  the  LAMARS  visual  system  is  limited  to  a 
180°  field  of  view  that  is  projected  on  the  inner  surface  of  the  dome.  The  LAMARS  is  typically  utilized  in  flying 
qualities  and  flight  control  research  simulations,  but  can  be  utilized  effectively  in  mission  simulations  as  well.  A 
picture  of  the  LAMARS  with  the  MS-1  in  the  background  can  be  seen  in  Fig.  2-2. 
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Fig.  2-2  LAMARS  (foreground)  and  MS-1 


2.S.2.3  Piloted  Combat  Stations 

The  Piloted  Combat  Stations  are  simulators  that  encompass  basic  cockpit  functionality  with  limited  out  the  window 
field  of  view.  They  are  a  lower  cost  alternative  to  adding  additional  manned  players  into  multi-ship  air  combat 
simulations  and  can  also  be  used  for  other  simulations  not  requiring  a  high  fidelity  cockpit  and  visual  system.  The 
basic  components  of  these  combat  stations  are  a  stick,  a  throttle  and  a  high  resolution,  29”  monitor  for  all  visual 
displays.  Stick  and  throttle  grip  types  can  be  reconfigured  as  needed  and  various  display  formats  can  be  utilized  to 
satisfy  a  given  simulation’s  requirements.  Currently,  AFRL/VACD  has  six  of  these  types  of  combat  stations,  one  of 
which  is  enhanced  with  projected  out-the- window  (OTW)  visuals.  A  picture  of  one  of  these  types  of  stations  can  be 
seen  in  Fig.  2-3. 


Fig.  2-3  Piloted  Combat  Station 


2.5.3  Simulation  Control  Consoles 

AFRL/VACD  controls  most  in-house  simulations  from  one  of  two  simulation  control  consoles.  The  first  console  is 
called  the  Flying  Qualities  Console  (FQC)  and  is  mainly  used  for  flying  qualities  and  flight  control  research 
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simulations.  The  FQC  is  a  relatively  small  console  that  contains  several  video  monitors,  one  VCR,  a  flight  stick,  and 
a  variety  of  lights,  buttons,  sliders  and  knobs  that  can  be  used  to  control  or  test  a  simulation. 

The  other  console  is  officially  called  the  Simulation  Control  Console  (SCC),  but  is  more  commonly  known  as  the 
MOAC  (Mother  Of  All  Consoles).  This  console  is  typically  used  for  the  multi-ship  combat  simulations  where  a  large 
number  of  monitors  are  required  to  view  all  aspects  of  the  simulation.  This  console  contains  numerous  video 
monitors,  three  VCRs,  a  flight  stick,  and  a  variety  of  lights,  buttons,  sliders,  and  knobs  that  can  be  used  to  control  or 
test  a  simulation. 

Both  consoles  and  all  simulator  stations  have  their  video  sources  controlled  by  a  facility  video  switch.  All  video  is 
controlled  by  this  switch  and  it  allows  the  simulation  engineer  the  ability  to  switch  any  video  source  to  any 
compatible  video  destination.  This  includes  video  for  console  monitors,  VCRs,  cockpit  displays,  HUDs,  projectors, 
etc.  There  is  also  the  capability  for  complete  video  setups  to  be  saved  to  a  file  called  a  salvo.  Salvos  allow  video 
configurations  to  be  reloaded  quickly  and  easily  without  the  simulation  operators  having  to  individually  program 
each  video  source  to  each  video  destination. 

2.5.4  AFRL/VACD  Simulation  Computers 

The  main  simulation  computers  utilized  in  the  AFRL/VACD  simulation  facility  are  manufactured  by  Encore 
Computing.  The  facility  uses  three  single  processor  RSX  computers  and  two  four  processor  Model  91  computers  for 
the  majority  of  the  simulation  model  processing.  The  RSX  computers  have  Encore's  MPX  real-time  operating  system 
and  the  91s  utilize  a  UNIX  based  operating  system.  These  computers  are  all  connected  together  via  a  reflective 
memory  bus  for  communication,  and  they  utilize  hardware  interrupts  between  the  computers  for  processor  activation 
and  control.  The  reflective  memory  bus  has  been  partitioned  to  allow  each  simulation  to  have  its  own  piece  of 
reflective  memory  for  implementing  their  particular  definition  of  Datapool.  Datapool  allows  all  of  the  simulation 
processes  access  to  most  or  all  of  the  simulation  data,  i.e.  aircraft  states,  weapon  states,  sensor  states,  simulator  states, 
etc.  Each  simulation  engineer  can  tailor  their  definition  of  Datapool  to  meet  the  requirements  of  their  particular 
simulation.  These  computers  also  communicate  with  other  simulation  support  computers  through  Ethernet  and 
SCRAMNet  rings. 

2.5.5  AFRL/VACD  Simulation  Support  Computers 

The  simulation  support  computers  at  the  AFRL/VACD  facility  consist  of  a  variety  of  Silicon  Graphics  computers,  a 
CAMAC  hardware  I/O  system,  an  Ensoniq  sound  system,  and  several  other  minor  components  that  may  be  needed  by 
a  given  simulation.  The  Silicon  Graphics  computers  are  used  to  generate  and  display  HUD  symbology,  the  head 
down  displays,  God’s  eye  displays,  high  resolution  targets,  and  any  other  graphics  that  may  be  required  by  the 
simulations.  The  CAMAC  hardware  I/O  system  allows  the  simulation  computers  to  communicate  with  all  of  the 
cockpit  hardware,  i.e.  sticks,  throttles,  etc.  The  hardware  is  configured  such  that  individual  simulator  stations  can  be 
added  or  removed  from  a  particular  simulation's  hardware  loop  through  the  use  of  a  programmable  fiber  optic 
highway  driver.  The  sound  system  is  also  tied  into  this  loop  and  is  driven  by  the  simulation  through  the  CAMAC 
system. 

2.5.6  AFRL/VACD  ESIG 

The  AFRL/VACD  facility  utilizes  two  Evans  &  Sutherland  4530  image  generators  for  the  majority  of  its  out  the 
window  scene  generation.  The  first  system  is  capable  of  generating  one  high  resolution  or  two  low  resolution  video 
channels  while  the  second  system  is  capable  of  generating  two  high  resolution  or  six  low  resolution  video  channels. 
These  image  generators  can  be  setup  to  run  at  30  Hz  or  60  Hz  rates  and  can  also  be  configured  to  run  synchronously 
with  the  simulation  computers.  When  running  synchronously,  the  image  generators  are  actually  controlling  the 
simulation  timing  instead  of  the  master  computer.  Communication  between  the  image  generators  and  simulation 
computers  can  be  performed  through  SCRAMNet  or  Ethernet,  but  synchronous  operation  can  only  be  accomplished 
via  SCRAMNet.  These  image  generators  have  access  to  several  different  databases  at  the  AFRL/VACD  facility. 
Databases  of  Lake  Mead,  Whidbey  Island,  Nellis  AFB,  and  Tyndall  AFB  are  available  for  use  by  in-house 
simulations.  Each  database  has  its  own  set  of  terrain  features,  moving  models,  and  animation  sequences  that  can  be 
activated  and  controlled  by  the  simulation  as  needed. 
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2.6  DASA  Simulation  Facility [DASA] 

2.6.1  Background/Introduction 

For  years,  department  MT64  (Simulation)  of  Daimler-Benz  Aerospace  has  been  working  on  the  interconnection  of 
flight  simulators  for  training  purposes  in  support  of  national  and  European  projects.  The  development  for  these 
projects  are  generally  based  on  ISDN-links,  concentrating  on  decreasing  the  network  load  and  raising  the  accuracy  of 
the  virtual  entities. 

The  main  focus  is  to  support  pilot  training  in  tactical  situations  that  are  difficult  or  dangerous  in  real  life  situations 
and  for  preparing  for  real  life  training. 

2.6.2  DASA  Simulators 

2.6.2.1  Integration  Cockpit 

The  Integration  Cockpit  is  a  small,  simple  generic  cockpit.  It  is  generally  used  for  development  and  integration. 
Nevertheless,  it  has  most  of  the  features  of  the  other  cockpits  and  encompasses  basic  cockpit  functionality.  It  is 
equipped  with  a  side  stick,  a  simple  throttle  and  a  high  resolution  monitor  for  all  main  head  down  displays.  If  needed 
it  is  possible  to  add  a  low  cost  backprojection  visual  system  for  a  limited  out-the- window  visual. 

2.6.2.2  VLO  Cockpit  -  Simulator 

The  VLO-Cockpit  is  a  transportable  cockpit  which  combines  the  simulation  computer  for  avionics  and  weapon 
systems  with  the  network  interface  computer  and  the  sound  system  in  a  single  unit.  The  system  is  an  extremely 
modular  design  and  easy  to  install  for  exhibitions  and  demonstrations. 

The  VLO-Cockpit  is  a  full  equipped  generic  cockpit  with  complex  stick  and  throttle,  three  standalone  high  resolution 
monitors  for  head-down-displays  (HDD)  and  a  head-up-display  (HUD).  For  an  out-the-window  view,  backprojection 
equipment  can  be  placed  in  front  of  the  cockpit. 

Additionally,  this  unit  can  generate  multiple  hostile  and  friendly  CGT’s  to  allow  the  cockpit  to  act  as  a  standalone 
training  simulator 

2.6.2.3  Dome  Simulator 

The  operators  view  of  the  outside  world  is  created  by  6  channel  CGI  which  can  display  4000  total  faces.  A  range  of 
databases  from  the  desert  to  New  York  can  be  loaded  and  filled  quickly  with  a  host  of  moving  models  and  special 
effects. 

The  images  can  be  displayed  in  a  9meter  6-channel  dome  or  on  individual  graphic  monitors.  Additionally,  the  dome 
allows  for  quick  replacement  of  different  cockpit  types  or  “crew  stations".  An  exchange  of  a  1.5  ton  cockpit  can  be 
performed  in  only  20  minutes. 

2.6.2.4  CGT  -  Computer  Generated  Targets 

For  the  most  complex  scenarios  multiple  Computer  Generated  Targets  were  involved  into.  These  CGT’s  ware  all 
running  on  one  SPARC-2CE  CPU-card  within  the  VLO-Cockpit-Simulator  as  shown  in  the  table  above.  Up  to  six 
CGT’s  were  used  at  least  in  a  scenario  especially  created  on  demand  of  the  pilots  to  enable  a  training  situation  with 
up  to  twelve  flying  entities.  All  these  six  CGT’s  were  running  on  the  same  CPU  within  a  20Hz  frame  rate. 

2.6.2.5  SAM  -  Surface  to  Air  Missile  Module 

This  module  models  the  radar  site  of  surface  to  air  missiles  on  the  fire  platoon  level  and  represents  the  Hawk  and 
patriot  missiles. 

This  Surface-to- Air-Missile  Module  provides  a  real-time  simulation  of  ground  based  threats  for  ComAO  scenarios.  It 
includes  modeling  of  radar  sites  and  missile  flyout.  Effects  of  IFF  and  jamming  are  included.  Combat  behavior  on 
the  Fire  Platoon  level  is  provided.  On  a  typical  graphical  user  interface,  the  actual  status  and  reaction  of  defined 
firing  positions  are  displayed.  Generic  models  for  HAWK  and  PATRIOT  are  available.  The  module  is  network 
capable. 
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2.6.3  Simulation  Control  Center 

2.6.3.1  Dome  Simulator 

The  simulation  is  controlled  and  monitored  from  a  control  room  equipped  with  20  color  monitors  to  keep  the 
operator  informed  of  every  detail. 

Additionally,  there  is  a  nearby  briefing  room  with  room  for  up  to  20  people  and  2  large  screen  to  view  and/or  review 
the  simulation  runs. 

2.6.3.2  Scenario  Manager 

This  module  is  used  to  setup  the  tactical  training  and/or  for  visualization  and  debriefing. 

For  setup,  you  can  configure  all  playing  entities  by  determining  the  type  and  role,  the  force  identification,  flares,  fuel 
and  the  armament.  All  entities  can  be  placed  at  an  initial  position  and  given  them,  particularly  the  CGT’s,  a  flight 
route  (bulls  eye  for  example). 

While  training,  the  Scenario  Managers  enable  the  user  to  watch  the  scenario  by  displaying  a  “God  Eyes  View“  or  a 
magnified  view  with  additional  information  such  as  speed  and  altitude. 

Another  very  important  function  is  the  ability  to  record  all  data  for  the  debriefing  of  the  networked  scenario.  This 
recorded  data  can  then  be  replayed  even  if  a  different  networked  training  session  is  performed  in  parallel. 

2.6.3.3  Fighter  Control  Station 

This  module  enables  a  fighter  controller  to  participate  within  the  training. 

This  module  is  a  generalized  replica  of  a  typical  fighter  controller  station  allowing  controllers  to  be  included  in 
virtual  ComAO  scenarios.  It  provides  a  user  interface  with  realistic  symbols  and  required  functionality.  It  is 
combined  with  a  voice  link  and  is  network  capable. 

2.6.4  DASA  Simulation  Computers 

2.6.4.1  VLO-  and  Integration  Cockpit 

A  FORCE  VME  system  using  Sparc  technology  is  used  for  simulation  of  the  avionics  and  weapon  model.  This 
system  enables  the  user  to  add  CPU-cards  for  increased  system  power  and  performance.  The  VME-bus  system 
allows  parallel  computing  of  avionics  simulation,  weapon  system  simulation,  Computer  Generated  Targets,  network 
interfacing  and  the  complete  synchronization  by  exchanging  data  via  a  standardized  shared  memory  architecture  for 
all  involved  simulation  systems.  This  simulation  platform  is  completely  integrated  within  the  VLO-Cockpit- 
Simulator. 

2.6.4.2  Dome  Simulator 

•  Simulation  Computer 

The  simulation  computer  has  8  parallel  Power  PC  604  Rise  (200Mhz)  processors  with  approximately  800  Mips 
total  performance,  128  MB  local-  and  32MB  global  memory.  The  input/output  is  handled  by  a  dual  high 
performance  VME-system.  It  is  controlled  by  a  UNIX  realtime  operating  system.  Data  is  exchanged  between  host 
computer  and  cockpits  via  fiber-optics  ScramNet  interfaces. 

•  G-system 

The  G-forces  encountered  by  the  crew  of  high  performance  aircraft  can  be  simulated  by  a  G-cueing  system 
consisting  of  a  G-seat  and  a  G-suit  driver. 

•  Sound  System 

Digital  recordings  of  the  original  sounds  can  be  mixed  together  under  computer  control  and  played  back 
synchronous  with  the  simulation. 
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Fig.  2-4Blockdiagram  of  the  Dasa  Dome  Simulation 


2.6.4.3  Additional  Modules 

The  networking  modules  as  the  Scenario  Manager,  SAM-Site-Module  and  the  Fighter  Control  Station  run  on  Silicon 
Graphics  computers. 

2.6.5  DASA  Database  Generators 

The  VLO  Cockpit-Simulator  and  the  Integration  Cockpit  can  use  three  different  quality  image  generators: 


•  an  ESIG  2000,  normally  used  with  the  VLO-Cockpit 

•  a  SGI  Onyx  with  Reality  Engine2,  a  good  alternative  to  one  of  the  other  IG’s 

•  a  SGI  02  as  a  simple  IG  for  integration  phases,  normally  used  with  the  Integration  Cockpit 

•  a  Compuscene  IV,  used  as  an  IG  for  the  Dome  Simulator. 

The  first  three  IG’s  are  completely  interchangeable  and  normally  connected  to  a  handy  backprojection  visual  system. 
For  all  four  IG’s  there  is  same  correlated  database,  Lake  Mead  area,  available,  allowing  all  the  simulators  to  be 
connected  together.  The  CGT’s  use  a  digital  map  of  this  area. 
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3.  TRACE  Simulation [DASA  &  AFRL] 

3.1  AFRL/VACD  Simulation [AFRL1 

3.1.1  Simulation  Hardware 

3.1.1.1  Computer  Systems 

3.1.1.1.1  Simulation  Processors 

The  TRACE  simulation  utilized  two  Encore  RSX  computers  and  two  Encore  91  Series  computers  for  the 
simulation  executive  and  model  processing.  A  maximum  of  seven  separate  processors  were  activated  on 
these  four  computers  for  the  TRACE  simulation  tests.  Tire  simulation  executive  was  configured  to  run 
synchronized  with  the  image  generation  systems  at  a  30  Hz  frame  rate.  Most  software  processes  were  run  at 
the  30  Hz  rate  while  some  of  the  display  drivers  were  run  at  15  Hz.  The  following  table  details  what 
simulation  software  was  running,  the  rate  it  was  scheduled  to  run,  and  the  processor  where  each  component 
was  located. 


Computer  System 

Processor  # 

Software/Process 

Rate 

Encore  RSX  (J) 

1 

Sim  Executive 

30Hz 

Hardware  I/O 

30Hz 

Network  I/O 

30Hz 

IG  Drivers 

30Hz 

Target  Projectors 

30Hz 

Missile  Warning  Sensor 

30Hz 

HDD  Drivers 

15Hz 

VBMS  Driver 

15Hz 

Encore  RSX  (G) 

1 

F-15  Model  (indexed) 

30  Hz 

HUD  Drivers 

30Hz 

20mm  Gun  /  Reticle 

30Hz 

Fire  Control 

30Hz 

Encore  91  (H) 

1 

Aircraft  #1  Missiles 

30Hz 

2 

Aircraft  #2  Missiles 

30Hz 

3 

Aircraft  #3  Missiles 

30Hz 

Encore  91  (1) 

1 

Radar  Model  (indexed) 

30Hz 

2 

Aircraft  #4  Missiles 

30Hz 

3.1.1.1.2  Graphics  Computers 

The  TRACE  simulation  incorporated  eight  Silicon  Graphics  computers  for  graphic  displays  processing. 
These  computers  handled  the  cockpit  displays,  HUDs,  high  resolution  target  image,  and  the  Virtual 
Battlefield  Management  System  (VBMS).  These  graphic  systems  are  driven  through  an  Ethernet  network 
that  operates  asynchronous  from  the  rest  of  the  simulation.  Displays  are  updated  by  the  simulation  display 
drivers,  at  the  rate  at  which  they  are  scheduled,  and  the  graphics  update  as  soon  as  they  receive  those  data 
packets.  The  following  table  details  where  all  of  the  individual  display  software  was  located. 
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Computer  System 

Model 

Graphics  Application 

Silicon  Graphics  #2 

4D/85GT 

F-15  HUD 

Silicon  Graphics  #3 

4D/85GT 

High  Resolution  Target 

Silicon  Graphics  #6 

4D/310VGX 

HDD/EFO  V 

Silicon  Graphics  #8 

4D/70GT 

HDD/EFO  V 

Silicon  Graphics  #9 

4D/85GT 

HDD/EFOV 

Silicon  Graphics  #10 

4D/85GT 

HDD/EFOV 

Silicon  Graphics  #15 

ONYX  RE2 

F-15  HUD/EFOV 

Silicon  Graphics  #20 

INDIG02 

VBMS 

3.1.1.13  Image  Generator 

The  TRACE  simulation  used  two  Evans  &  Sutherland  model  4530  image  generators  for  controlling  the 
OTW  visual  scene  in  the  MS-1  and  Super  MCS.  The  Lake  Mead  database,  converted  by  DASA,  was 
utilized  to  ensure  that  both  ends  of  the  network  simulation  were  flying  over  the  same  terrain.  As  mentioned 
earlier,  the  TRACE  simulation  was  configured  to  run  synchronously  with  these  image  generators  at  a  30  Hz 
frame  rate. 

3.1.1.2  Simulator  Stations 

The  TRACE  simulation  utilized  up  to  four  different  cockpits  at  the  AFRL/VACD  Flight  Simulation 
Facility.  The  first  is  a  40  ft  diameter  dome  called  the  Mission  Simulator  1  (MS-1).  The  second  cockpit  is  a 
manned  combat  station  called  the  Super  MCS,  while  the  remaining  two  stations  are  generic  manned  combat 
stations.  All  stations  are  connected  to  a  common  intercom  system  that  can  be  configured  to  allow 
communication  between  any  combination  of  stations  that  is  desired.  In  the  TRACE  simulation,  all  stations 
could  communicate  with  each  other. 

3.1.1.2.1  Mission  Simulator  1 

The  MS- 1  cockpit  is  placed  on  a  platform  so  the  pilot's  head  is  located  approximately  in  the  center  of  the 
dome  while  flying.  A  visual  scene  is  projected  on  the  inner  surface  of  the  dome  by  two  General  Electric 
light  valve  projectors  with  the  video  generated  by  two  channels  from  an  Evans  &  Sutherland  4530  computer 
image  generator.  The  first  channel  provides  video  for  all  of  the  front  hemisphere  except  for  the  40°  area  of 
interest  (AOI)  cutout.  The  second  channel  has  a  40°  diameter  field-of-view  which  is  inset  into  the  AOI 
cutout  and  provides  high  resolution  imagery  directly  in  front  of  the  pilot.  The  visual  scene  moves  in 
reaction  to  pilot  flight  control  inputs  and  provides  visual  flight  capability.  The  visual  cues  give  a  sensation 
of  motion;  however,  the  cockpit  does  not  move  at  any  time. 

Two  types  of  target  projectors  are  used  to  display  other  vehicles.  One  high  resolution  color  target  projector 
pair  provides  a  high  quality  depiction  for  one  vehicle.  Four  laser  target  projector  pairs  provide  wire-frame 
drawings  for  up  to  4  more  vehicles.  The  high  resolution  projector  and  laser  projectors  display  the  aircraft 
on  the  dome  surface  in  all  quadrants  and  provide  sufficient  cues  of  target  range,  aspect  angle,  and  flight  path 
for  visual  air-to-air  engagements. 

A  high  resolution  29"  monitor  is  used  in  the  cockpit  to  present  the  simulated  advanced  head  down  display. 
Cockpit  2000.  There  is  no  actual  HUD  hardware  in  the  MS-1  cockpit,  so  the  HUD  is  simulated  by 
projecting  it  onto  the  dome  at  the  appropriate  location  in  front  of  the  pilot.  However,  actual  F-15  center 
stick  and  dual  throttle  grips  were  integrated  into  the  simulator.  Some  pictures  of  the  inside  of  the  MS-1  can 
be  seen  in  Fig.  3-1. 
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Fig.  3-1  MS-1  Internal  Views 


3.1.1.2.2  Manned  Combat  Stations 

The  Manned  Combat  Stations  consist  of  a  generic  cockpit  shell  platform,  highback  seat,  a  high  resolution 
29"  monitor,  and  F- 15  stick  and  throttle  grips.  No  rudder  pedals  are  incorporated,  but  there  is  a  footrest 
built  into  the  cockpit  shell.  Each  MCS  is  located  in  its  own  individual  room  to  keep  that  station  isolated 
from  unwanted  ambient  light  and  noise. 

3.1.1.2.3  Super  Manned  Combat  Station 

The  Super  MCS  is  the  same  as  the  above  described  manned  combat  stations  with  the  following  exceptions. 
The  Super  MCS  has  a  53.64°  wide  by  42.93°  high  Field-of-View  (FOV),  high  resolution,  Out-The-Window 
(OTW)  image  projected  onto  the  wall  in  front  of  the  cockpit.  This  image  is  also  generated  by  an  Evans  & 
Sutherland  4530  image  generator  and  is  video  key-mixed  with  a  HUD/EFOV  graphics  prior  to  being 
projected  at  the  simulator  station.  This  provides  the  Super  MCS  with  OTW  visuals  and  a  HUD,  neither  of 
which  are  found  in  the  standard  MCS.  The  Super  MCS  also  has  a  newer  cockpit  shell  design  modeled  after 
the  F-22  cockpit  ergonomics,  but  using  the  F-15  stick  and  throttle  grips  like  the  other  manned  combat 
stations.  Two  pictures  of  this  station  can  be  seen  in  Fig.  3-2. 
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3.1.2  Simulation  Software 

3.1.2.1  Simulation  Executive 

The  TRACE  simulation  executive  is  FORTRAN  based  software  that  allows  for  the  scheduling  and 
activation  of  all  of  the  simulation  components  across  multiple  computers  and  processors.  The  individual 
components  can  be  written  in  FORTRAN,  C,  C++,  or  ADA.  The  executive  software  was  developed  by 
engineers  from  AFRL/VACD  and  Halifax,  the  on-site  contractor,  and  is  updated  periodically  to  incorporate 
new  facility  hardware  and/or  software.  A  basic  simulation  executive  shell  is  maintained  and  used  as  a 
starting  point  for  building  nearly  ail  in-house  simulations. 

The  executive  allows  the  simulation  operators  to  create  schedules  for  all  of  the  simulation  components 
based  on  whole,  even  multiples  of  the  base  simulation  frame  rate,  which  is  33.3333  ms  in  the  TRACE 
simulation  (30  Hz).  Various  combinations  of  schedules  can  be  saved  and  reloaded  as  needed  for  a  given 
simulation  test.  The  executive  also  allows  the  simulation  operator  to  turn  on/off  all  of  the  various 
processors  that  are  utilized  by  a  given  simulation.  A  system  of  menus  and  data  files  have  been  implemented 
to  allow  the  operator  to  load  in  various  initial  conditions  for  each  simulation  run.  These  data  files  include 
information  on  aircraft  positions,  velocities,  fuel  load,  weapons  load,  waypoint  data,  etc.  and  can  also  be 
saved  and  reloaded  as  needed  by  the  operator. 

One  modification  that  was  made  to  the  standard  executive  for  the  TRACE  simulation  was  the  ability  for  our 
simulation  to  receive  an  Execute  Command  PDU  from  DAS  A  across  the  network.  The  AFRL/VACD 
simulation  would  sit  in  its  initial  condition  state  until  this  PDU  was  received  and  then  it  would  begin 
running  real-time  without  the  in-house  operator  commanding  this  locally.  This  gave  us  the  capability  to 
synchronize  the  start  of  the  simulation  test  runs  with  DASA.  Other  than  that  modification,  the  simulation 
executive  remained  essentially  the  same  as  all  of  our  other  in-house  simulations. 

3.1.2.2  Simulation  Models 

3.1.2.2.1  Aircraft 

The  aircraft  model  that  was  utilized  in  the  TRACE  simulation  was  a  5  DOF,  unclassified  performance 
model  of  an  F-l  5C.  This  model  was  written  in  FORTRAN  and  originated  from  McDonnell  Douglas  in 
support  of  the  ICAAS  simulation  program.  The  model  has  internal  indexing  that  allows  for  up  to  eight 
aircraft  to  be  simulated  from  a  single  process.  The  maximum  number  of  aircraft  simulated  for  the  TRACE 
tests  at  the  AFRL/VACD  facility  was  four.  No  digital  aircraft  were  simulated  on  the  US  side. 

3.1.2.2.2  Radar /IFF 

The  AFRL/VACD  simulation  facility  was  in  the  process  of  integrating  a  new  radar  model  into  the 
simulation  environment  when  the  TRACE  tests  occurred.  Because  of  this,  only  a  subset  of  the  APG-63 
radar  system  was  available  for  use.  Only  the  Track- While-Scan  (TWS)  mode  was  available  and  Doppler 
effects  were  not  yet  included.  The  IFF  system  was  a  simplistic  identification  model  that  returned  truth  data 
for  FFN  ID  and  aircraft  type  for  all  radar  tracks.  The  effects  of  terrain  were  also  not  incorporated  in  the 
radar  model,  although  DASA  did  provide  AFRL/VACD  with  a  routine  to  determine  if  line  of  sight  between 
objects  was  blocked  by  terrain.  For  the  purpose  of  the  TRACE  tests,  a  constant  radar  cross  section  (RCS) 
was  agreed  upon  to  be  used  at  all  times  by  the  sensors,  regardless  of  target  aspect. 

The  radar  model  is  an  adaptation  of  the  Eidetic  Radar  Model.  It  contains  most  of  the  original  code,  but  uses 
a  different  detection  algorithm.  It  is  also  written  in  the  C++  programming  language,  which  allow  multiple 
instances  of  radar’s.  All  of  the  radar  calls  are  by  methods  of  the  radar  class.  Object  control  is  through  an 
array  of  all  players  in  the  simulation.  An  object  or  player  may  or  may  not  have  an  associated  radar. 
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3 , 12. 2.2.1  Initialization 

Simulation  interface  is  through  common  memory  called  datapool.  Datapool  contains  all  object’s  state  data, 
the  radar  sensor  settings,  the  radar  track  data,  and  other  simulation  related  data.  Upon  initialization  the 
following  happen: 

a.  A  radar  is  instantiated  for  each  player  that  has  a  radar. 

b.  The  sensor  data  is  read  which  initializes  each  radar. 

c.  The  radar  track  data  variables  are  initialized  to  a  clear  state.  There  are  multiple  methods  to 
instantiate  each  radar  so  it  will  be  associated  with  the  correct  player. 

d.  The  initial  radar  scan  is  started  by  positioning  the  antenna  to  its  start  position. 

e.  The  radar  ran  in  Track  While  Scanning  mode.  This  allows  multiple  targets  tracks  and  a  lock  on  for 
a  selected  target. 

3.12222  Execution 

The  operation  portion  of  the  radar  is  controlled  by  5  distinct  steps.  These  steps  are  updated  every  frame. 
Every  instantiated  radar  executes  these  loops  each  frame. 

a.  The  radar  sensor  data  is  read  for  possible  changes  in  the  functionality  of  the  radar. 

b.  The  next  operation  is  to  calculate  this  radar’s  signal  strength  at  the  target.  This  is  used  for  the 
ownship’s  detection  of  targets  and  for  other  object’s  radar  warning  returns.  These  are  represented 
in  an  array  which  is  a  member  of  the  radar  class.  These  values  are  written  to  datapool  as  radar 
track  data  as  the  last  operation  of  the  loop. 

c.  State  data  is  used  to  calculate  the  relative  geometry  of  each  possible  target.  Each  player’s  state 
data  is  read  from  datapool  and  the  corresponding  math  operations  are  performed.  Some  of  those 
operations  are  azimuth,  elevation,  range  to  target,  azimuth  from  target,  elevation  from  target  and 
others. 

d.  The  radar  loop  is  entered.  This  is  a  series  of  operations  that  determine  if  this  radar  detects  a  target 
and  if  the  target  information  will  be  made  known  to  the  pilot.  The  radar  antenna  scans  a  defined 
scan  volume.  This  is  done  in  increments  as  the  antenna  is  moved  through  the  scan  volume.  These 
questions  are  asked  for  each  of  these  segments: 

1.  Is  the  beam  looking  at  the  target;  i.e.,  is  the  target  in  the  scan  volume? 

2.  Is  the  object  detected;  i.e.,  what  is  the  signal  strength  value?  If  the  signal  strength  value  is 
within  a  set  limit,  the  target  is  considered  to  have  had  a  hit.  It  is  necessary  for  three 
consecutive  hits  to  establish  a  track.  Five  consecutive  misses  constitute  a  track  loss. 

3.  The  target’s  signal  to  noise  ratio  is  calculated  for  detection  consideration. 

e.  The  radar  beam  is  incremented  in  the  scan  volume. 

f.  The  radar  track  information  is  written  to  datapool.  If  the  object  is  within  the  scan  volume,  but  out 
of  range,  the  object  is  not  reported  as  detected  to  the  pilot.  However,  the  calculated  signal  strength 
for  each  target  is  placed  in  datapool.  This  is  used  for  RWR  warning  by  other  objects. 

3.1222.3  Radar  Signal  Patterns  and  Radar  Detection 

In  this  simulation  it  was  attempted  to  model  the  radar  detection  as  accurately  as  possible.  The  radar 
detection  issue  is  a  matter  of  concern.  What  manner  of  detection  closely  models  a  real  radar,  and  should 
detection  only  occur  if  the  target  is  within  the  defined  scan  volume?  There  appear  to  be  three  basic 
considerations  that  determine  signal  detection: 

•  What  is  the  maximum  range  at  which  a  signal  can  be  detected? 

The  maximum  range  could  be  ambiguous  because  another  factor  is  the  radar  cross  section  of  the 
target .  If  the  range  is  set,  a  different  radar  cross  section  should  alter  the  returned  signal,  but  with 
the  range  set  it  would  not  matter. 

•  Where  does  the  signal  to  noise  ratio  equal  one? 
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The  signal  to  noise  ratio  would  depend  on  the  receiver  being  modeled. 

•  What  is  the  minimum  level  for  a  signal  to  be  detected? 

A  set  level  for  detection.  Covers  the  differing  range  and  radar  cross  section  values. 


The  minimum  detection  level  was  used  for  the  TRACE  project.  This  level  was  set  at  100  micro  watts 
at  the  target  as  calculated  by  the  transmitting  radar.  The  formula  used  is: 


signal  - 


fact 1  *  RCS 
fact 2  *  R 4 


where: 

fact  1  =  />„„  *  T,  *  PRF  *  L.  *  X  *  G  *  Cmr 


Ppeak  =  peak  power 
G  =  gain 

Grcvr  =  receiver  gain 
L  =  loss 

La  =  Antenna  efficiency  loss 
TP  -  pulse  width 

and 

fact!  =  4jt3  *  Nrcvr  *T0*k*  BW 

T0  =  receiver  temperature  (290K) 

BW  =  bandwidth 
Nrcvr  =  receiver  noise 
k  =  Boltzmann’s  constant. 

This  gives  a  radar  emission  pattern  of  a  constant  circle  surrounding  the  emitting  radar.  To  emulate  the 
radar  lobes  more  closely  a  sync(x)  function  was  added  to  the  formula.  This  provides  a  main  lobe 
emanating  in  the  direction  the  antenna  is  pointing  with  several  side  lobes  also  present.  The  graph 
below  is  a  representation  of  the  main  lobe.  The  sync(x)  signal  provides  a  value  of  0.0  to  1.0.  This 
applied  to  the  signal  calculated  using  the  above  formula  and  because  of  the  nature  of  the  sync(x),  the 
main  lobe  becomes  apparent.  We  held  radar  cross  section  at  a  constant  at  25  square  meters  because  of 
network  constraints.  The  values  used  are: 


radar  cross  section 

25  square  meters 

peak  power 

3000  watts 

pulse  width 

2.4  e-6  seconds 

prfl 

950  hz 

prf2 

3000  hz 

prf3 

125000  hz 

main  lobe  loss 

0.03 

wave  length 

0.03 

gain 

3800 

receiver  noise 

15.0 

receiver  temp 

290.0  K 

band  width 

10.0  Mhz 

range 

40.0  nm. 
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These  values  represent  generic  radar  parameters.  Peak  power,  gain,  and  radar  cross  section  were  values 
supplied  by  DASA  to  make  the  two  radars  uniform. 


Chart  Explanation: 

This  chart  is  the  visual  representation  of  how  the  sync(x)  modifies  the  original  Edietic  model  radar  pattern. 
The  pattern  looks  very  symmetrical  and  that  is  because  this  is  plotted  with  only  36  points.  If  more  points 
are  added,  additional  side  lobes  become  apparent.  This  plot  is  to  show  the  overall  effect.  The  antenna  of 
the  radar  is  in  the  center  of  the  large  circle  and  is  pointing  up.  This  is  a  360  degree  representation  of  the 
radar  model  emission  pattern.  The  values  used  are  those  identified  above.  The  lOlog(Eidetic)  is  the 
original  360  degree  pattern  that  would  emanate  from  the  center  of  the  circle.  The  other  three  plots  are 
emission  patterns  effected  by  the  sync(x)  signal.  Three  pulse  rates  are  used  to  show  the  difference  is  range 
coverage. 

This  diagram  demonstrates  the  validity  of  using  signal  strength  for  detection  as  well  as  field  of  view.  The 
advantages  of  the  sync(x)  signal  is  a  way  of  modeling  a  radar  signal  pattern  with  a  main  lobe. 


3.1.2.2.3  Weapons 

The  TRACE  simulation  utilized  three  different  weapon  models  during  the  TRACE  development  and  test 
phases:  medium  range  missile  (MRM),  short  range  missile  (SRM),  and  20mm  gun.  The  two  missile  models 
were  provided  by  DASA  to  AFRL/VACD  as  part  of  a  data  exchange  agreement  with  the  TRACE  program. 
The  gun  model  was  provided  to  DASA  from  AFRL/VACD,  also  as  part  of  the  data  exchange  agreement. 

The  exchange  of  these  models  allowed  the  simulation  engineers  to  employ  the  same  weapon  models  on  both 
ends  of  the  networked  simulation.  This  created  somewhat  of  a  baseline  from  which  to  proceed.  All  weapon 
flyouts  were  performed  locally  at  the  firing  aircraft’s  simulation  site.  The  only  exception  to  this  was  the 
implementation  of  the  flare  effects  model.  Release  of  flares  by  a  target  aircraft  caused  activation  of  the  flare 
effects  model  at  the  firing  aircraft’s  simulation  site,  which  typically  was  on  the  other  side  of  the  network 
from  the  target.  All  kill  determination  was  also  performed  at  the  weapon  activation  site  with  the  results 
being  transmitted  to  the  target's  site  upon  completion.  The  capabilities  of  each  weapon  as  well  as  the 
operational  implementation  of  the  weapons  in  the  simulation  is  described  in  the  following  sections. 

3 A 223 A  Missiles 

The  TRACE  missile  models  provided  by  DASA  were  designed  as  stand-alone  models  for  a  single  aircraft 
only.  Therefore,  each  aircraft  in  the  simulation  required  its  own  missile  model  process  to  be  run  on  separate 
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processors  within  the  simulation  environment.  The  models  that  were  controlled  by  these  missile  processes 
are  described  in  the  following  sections. 

3.1. 2.2.3. 1.1  Missile  Launch  Envelope 

The  missile  models  provided  by  DASA  included  the  appropriate  missile  launch  envelope  (MLE) 
routines  for  determining  the  different  effective  launch  ranges  based  on  predefined  target  evasion  criteria. 
The  launch  ranges  computed  are  defined  as  follows: 


Nomenclature 

Missile 

Definition 

Rmaxl 

MRM /SRM 

Target  performs  3G  turn  at  end  game 

Rmax2 

MRM 

Target  performs  6G  turn  and  run  at  range  to  go  <  10  Km 

Rmin 

MRM / SRM 

Minimum  range  for  missile  arm 

These  MLE  data  were  determined  and  updated  as  long  as  certain  minimum  conditions  were  met  as 
described  in  the  following  sections. 

3. 1 .2.2.3. 1 .2  Medium  Range  Missile 

The  medium  range  missile  model  is  an  unclassified,  generic  version  of  an  advanced,  medium  range  air-to- 
air  missile  (AMRAAM).  The  requirement  for  firing  an  MRM  is  the  ownship  has  to  be  tracking  the  target 
with  radar  as  the  primary  designated  target  (PDT).  If  so,  MLE  data  is  computed  and  displayed  on  the  HUD 
to  let  the  pilot  decide  when  to  fire  the  missile.  The  model  incorporates  the  capability  of  the  missile  to 
achieve  an  autonomous  state,  meaning  it  is  capable  of  tracking  the  target  aircraft  with  sensors  onboard  the 
missile  without  requiring  a  guidance  beam  from  the  launching  aircraft.  The  point  at  which  the  missile 
becomes  autonomous  depends  on  the  relative  state  data  between  the  missile  and  the  target.  The  point  at 
which  the  missile  goes  autonomous  is  indicated  to  the  pilots  on  the  situation  display  so  they  will  know  when 
they  no  longer  need  to  illuminate  that  particular  track  with  the  onboard  radar  for  that  particular  missile. 

3. 1 .2.2.3. 1 .3  Short  Range  Missile  /  Flares 

The  short  range  missile  model  is  an  unclassified,  generic  version  of  an  infrared  seeker  based  missile  similar 
to  the  AIM-9  Sidewinder.  The  requirement  for  firing  an  SRM  is  the  ownship  has  to  be  tracking  the  target 
with  radar  as  the  PDT  and  the  SRM  seeker  has  to  have  IR  lock-on  detection.  If  these  two  conditions  are 
met,  MLE  data  is  computed  and  displayed  on  the  HUD  to  let  the  pilot  decide  when  to  fire  the  missile.  The 
IR  Seeker  lock-on  is  indicated  to  the  pilot  by  a  lock  on  tone  in  the  headset  as  well  as  a  change  in  the  SRM 
symbology  on  the  HUD.  Once  fired,  the  SRM  immediately  becomes  autonomous  and  no  longer  requires 
ownship  guidance.  The  model  also  includes  flare  effects  to  allow  for  implementation  of  countermeasures. 
The  flare  model  itself  is  built  in  to  the  missile  model  and  is  processed  for  each  SRM  as  flares  are  released 
by  the  target  aircraft. 

3222.32  Gun 

The  gun  model  used  in  the  TRACE  simulation  is  an  unclassified,  generic  20mm  gun  model  that  was  indexed 
to  be  able  to  process  bullet  flyouts  for  up  to  eight  different  aircraft  in  a  single  process.  The  requirement  for 
firing  the  gun  is  the  ownship  has  to  be  tracking  the  target  with  radar  as  the  PDT.  If  so,  a  lead  computed 
optical  sight  (LCOS)  reticle  position  is  computed  and  displayed  on  the  HUD  to  indicate  where  the  bullet 
would  be  at  the  target's  range  had  it  been  fired  one  time  of  flight  ago.  Maximum  effective  bullet  time  of 
flight  was  defined  as  1.5  seconds.  The  gun  model  counts  bullet  hits  and  accumulates  Pk  values  for  the  target 
aircraft  until  a  value  of  0.80  is  reached;  at  which  point  the  target  is  declared  killed. 

3.1.2.2.4  Missile  Warning 

The  AFRL/VACD  TRACE  team  was  not  able  to  get  the  radar  warning  receiver  (RWR)  integrated  prior  to 
the  piloted  tests  so  a  generic  missile  warning  sensor  was  incorporated  to  give  the  pilots  information  about 
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when  they  were  fired  on  by  a  radar  guided  missile.  This  sensor  activated  warning  lights  on  the  cockpit 
panel  that  indicated  the  ownship  was  being  fired  on  by  a  radar  missile.  No  information  on  missile  range  to 
ownship  or  azimuth  data  was  provided  to  the  pilot  unless  the  ownship  was  tracking  the  launching  aircraft  on 
radar  at  the  time  of  launch.  If  so,  a  red  dashed  line  would  appear  connecting  the  ownship  symbol  on  the 
situation  display  to  the  target  aircraft  that  launched  the  missile.  If  the  ownship  lost  the  launching  aircraft  as 
a  track  while  turning  away  to  defeat  the  missile,  the  dashed  line  would  disappear.  The  warning  lights 
remained  on  until  the  missile  hit  or  failed  and  its  flyout  completed  no  matter  what  the  ownship's  radar  track 
status  was.  No  warnings  are  provided  to  the  pilot  for  IR  missile  launches. 

3.1.2.3  Displays  and  Controls 

3.1.23.1  Head  Down  Display 

This  section  gives  general  descriptions  of  the  major  components  of  the  Cockpit  2000  main  instrument  panel 
display  as  shown  in  Fig.  3-4.  This  display  is  presented  to  the  pilot  as  a  single  graphic  format  on  a  high 
resolution  29"  monitor. 


3. 1.2.3. 1. 1  Description  and  Function 

The  Main  Instrument  Panel  includes  two  6x6  inch  multipurpose  displays  (MPDs)  and  a  large  9.5  x  9.5 
inch  multipurpose  display,  all  of  which  will  have  8-color  capability.  The  eight  colors  used  are  red,  yellow, 
green,  blue,  cyan  (light  blue),  orange,  white,  and  magenta  (light  purple). 

Multipurpose  Displays  -  All  symbol  color  coding  complements  shape,  size,  and  dynamic  (e.g.,  flashing) 
codes.  Color  coding  aids  quick  interpretation  of  complex  formats  such  as  the  A/A  Sensor  display  in 
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realistic  scenarios  and  it  contributes  to  an  easy,  accurate  assessment  of  the  tactical  situation.  Symbol  shapes 
and  color  coding  are  covered  in  more  detail  in  later  sections. 

Large  Multipurpose  Display  -  This  9.5  x  9.5  inch  display  is  similar  to  the  MPDs,  but  it  has  2  1/2  times 
more  area  than  the  6  x  6  inch  MPDs,  providing  an  inherent  declutter  feature. 

Display  Sequencing  -  To  simplify  operation  each  MPD  has  been  programmed  to  provide  direct  access  to 
display  formats  via  the  HOTAS  stick  castle  switch. 

3. 1.2.3. 1.2  Instruments 

The  TRACE  simulation  cockpits  are  similar  to  most  modern  combat  aircraft  in  that  primary  flight 
information  is  located  on  a  HUD  in  each  station.  This  information  is  augmented,  however,  by  a  standby 
Attitude  Direction  Indicator  (ADI)  ball  next  to  the  upfront  control,  a  Vertical  Velocity  Indicator  (VVI), 
Angle  of  Attack  (AO A)  meter,  Altimeter  and  several  warning  lights  on  the  instrument  panel. 

3. 1.2.3. 1.3  Multipurpose  Display  Formats 
3. 1.2.3. 1.3.1  Air-to-Air  Sensors  Format 

The  A/A  Sensors  format  provides  a  familiar  interface  with  the  radar.  Its  purpose  is  to  display  targets  and 
weapon  attack  parameters.  The  A/A  Sensors  format  shown  in  Fig.  3-5  is  normally  located  on  the  right 
MPD,  but  can  be  selected  on  the  center  MPD  using  the  castle  switch  or  on  any  MPD  by  selecting  from  the 
main  menu.  This  azimuth  versus  range  display  is  very  similar  to  that  of  the  F-15E  with  its  APG-70. 
Displayed  target  symbols  represent  radar  track  files  only  since  an  IRST  sensor  was  not  implemented  in  the 
TRACE  simulation. 
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3. 1.2.3. 1.3. 1. 1  Target  Symbols 

Target  symbology  for  hostile,  friendly,  and  unknown  targets,  as  well  as  PDT  and  Next  Shot,  are  represented 
(Fig.  3-6). 

Hostile  Threats  -  Targets  positively  identified  as  threats  are  shown  as  red  triangles.  The  shape  of  the 
triangles  further  indicates  whether  the  target  is  a  fighter  or  bomber. 

Unknowns  -  If  a  target  can't  be  identified  by  aircraft  type  it  will  be  shown  as  a  box.  An  unknown  may  be 
identified  as  hostile  by  other  means,  in  which  case  it  will  be  colored  red.  A  complete  unknown  will  be 
yellow. 

Friendly  -  Other  than  ownship,  friendlies  will  be  green  circles  with  heading  vectors. 

Heading  Vector  -  A  target's  heading  vector  is  displayed  as  a  line  segment  originating  from  the  symbol's 
"nose."  Any  target's  heading  can  be  estimated  by  comparing  the  orientation  of  this  vector  with  ownship. 


Radar 

Tracks 

Unknown 

■ 

Hostile 

Fighter 

T 

Bomber 

Unknown 

1  1 

*T 

Friendly 

f 

Color 

Code 

Red 

Red 

Red 

Yellow 

Green 

Primary  Designated  Next  Shot 

Target  Target 


Gr*«n  Boi  Grttn  X 


Fig.  3-6  Target  Symbology 


3. 1.2.3. 1.3. 1.2  Grid  Lines 

The  horizontal  grid  lines  divide  the  format  into  four  equal  sections  which  helps  the  pilot  estimate  range 
based  on  the  selected  scale.  Vertical  grid  lines  that  help  show  target  azimuth  are  drawn  at  0  degrees  and  ± 

30  degrees.  The  left  and  right  edges  of  the  grid  represent  azimuth  field  of  regard  limits  of  ±  60  degrees 
which  encompasses  the  capability  of  the  radar. 

3. 1.2.3. 1.3. 1.3  Elevation  Scale 

Along  the  left  edge  of  the  grid  a  scale  is  provided  that  represents  ±  30,000  feet  of  altitude.  The  altitude  of  a 
track  is  shown  digitally  to  the  right  of  the  track  symbol  when  a  target  is  cursor  captured. 

3. 1.2.3. 1.3. 1.4  Azimuth  Scale 

Along  the  bottom  edge  of  the  grid  an  azimuth  scale  is  provided.  Tic  marks  are  shown  every  10  degrees 
until  ±  30,  then  again  at  ±  60  degrees.  Circles  show  the  left  and  right  azimuth  angle  limits  of  the  radar.  The 
vertical  lines  on  the  display  indicate  azimuth  lines  from  the  ownship.  Targets  pointing  straight  down  at  any 
azimuth  and  range  are  actually  pointing  right  at  the  ownship.  This  is  the  same  as  the  standard  B-scope  type 
radar  display  used  in  many  current  combat  aircraft. 


3-11 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-01 


Final  Report 
3.  TRACE  Simulation 


3. 1.2. 3. 1.3. 1.5  Acquisition  Cursor 

This  symbol  incorporates  the  cursor  functions  of  cursor  capture,  range  selection  and  display  selection 
control.  "Cursor  capturing"  a  target  provides  altitude  and  airspeed  data  adjacent  to  the  captured  target.  The 
cursor  bars  are  solid  if  assigned  to  this  format,  and  dashed  when  assigned  to  another  MPD. 

3A2.3A3.L6  Range  Scale 

Shown  above  the  upper  right  comer  of  the  grid,  this  indicates  the  range  in  nautical  miles  from  the  bottom  to 
the  top  of  the  grid.  Ranges  of  10,  20,  40,  80,  160  and  320  nm  are  selectable  by  bumping  the  top  or  bottom 
of  the  grid  with  the  acquisition  cursor.  Bumping  range  on  this  format  does  not  affect  the  other  formats. 

3.123A.3A.7  Ownship  Data 

Calibrated  airspeed  and  altitude  (in  thousands  of  feet)  are  displayed  to  the  left  and  right  of  the  ownship 
symbol  respectively.  A  pitch  and  bank  indicator  is  provided  in  the  center  of  the  format  to  aid  the  pilot  in 
head  down  aircraft  control. 

3.1 .2.3.1 .3.2  Situation  Display 

The  Situation  Display  format  is  very  similar  to  the  air-to-air  sensors  format  with  the  following  exceptions. 
The  viewport  layout  is  designed  as  a  top  down  view  of  the  ownship  and  its  surroundings  with  track 
locations  positioned  by  azimuth  and  range.  A  compass  rose  encircles  the  ownship  symbol  for  referencing 
heading  data  and  the  scenario  waypoints,  if  any,  can  be  viewed  by  selecting  the  route  (RTE)  button  on  the 
left  side  of  the  display.  The  range  scale  of  the  display  is  controlled  by  range  bumping  or  by  toggling  the 
range  scale  up  or  down  from  the  range  control  buttons  on  the  upper  right  hand  of  the  display.  The  Situation 
Display  uses  two  range  rings  centered  on  the  ownship  for  range  reference  lines;  one  at  half  of  the  current 
display  range  and  the  other  at  full  display  range.  Indicated  range  is  measured  from  the  ownship  symbol  to 
the  top  edge  of  the  display.  Tracks  are  positioned  in  azimuth  on  the  display  along  imaginary  radial  lines 
that  are  measured  relative  to  the  ownship  longitudinal  body  axis  as  opposed  to  the  implementation  of  the  B- 
scope  azimuth  view  scheme  found  on  the  A/A  Sensors  format.  Ownship  pitch  and  bank  indicators  are  not 
included  in  the  Situation  Display  format.  All  other  target  and  ownship  information  is  presented  in  the  same 
manner  as  the  A/A  Sensors  format,  including  target  symbology,  ownship  data,  cursor  capturing,  etc.  An 
example  view  of  the  Situation  Display  format  can  be  seen  in  Fig.  3-7. 
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3. 1.2.3. 1.3.3  Weapons  Format 

The  weapons  (WPNS)  format  displays  status  of  ownship  weapons,  fuel,  and  countermeasures  (Fig.  3-8). 
Digital  readouts  for  gun  rounds,  fuel  (lb.),  chaff,  and  flare  are  provided  along  with  graphical  depictions  of 
the  SRMs  and  MRMs  on  board  the  aircraft.  MRMs  are  color  coded  with  yellow  lines  and  yellow  fill  while 
the  SRMs  utilize  red  lines  and  red  fill.  The  filled  missile  symbol  indicates  which  missile  is  the  next  one  of 
that  type  to  be  fired,  while  hollow  missile  symbols  indicate  number  of  additional  SRMs  and  MRMs 
currently  on  board.  After  a  missile  is  fired,  the  graphical  symbol  for  that  missile  is  removed  and  the  next 
missile  of  that  type  to  be  fired  is  filled. 


3-13 


Final  Report 
3.  TRACE  Simulation 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-01 


MRM  to  be  fired 
(yellow  fill) 


SRM  to  be  fired 
(red  fill) 


Fig.  3-8  Weapons  Display  Format 


3.1.2.3.2  HUD  Symbology 

The  HUD  symbology  is  basically  the  same  as  the  F-15E  HUD  symbology  with  some  modifications  to 
reduce  clutter  and  to  meet  research  simulation  needs.  MRM,  SRM  and  Gun  modes  are  all  supported.  An 
example  view  of  the  HUD  used  in  the  TRACE  simulation  can  be  seen  in  Fig.  3-9. 
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3. 1.2.3. 2.1  MLE  Scale 

The  HUD  MLE  scale  will  automatically  change  ranges  so  that  Rmax  is  located  between  full  and  half  range, 
regardless  of  PDT  range. 

3.1.2.3.2.2  Shoot  Cue 

This  cue  is  positioned  below  the  TD  box  and  appears  when  all  conditions  for  a  valid  missile  shot  are 
satisfied.  The  MRM  shoot  cue  is  a  star  and  the  SRM  shoot  cue  is  a  triangle. 

3. 1.2.3.2.3  Next  Shot  Cross 

The  open  cross  symbol  functions  similar  to  the  TD  box,  except  it  indicates  the  position  in  azimuth/elevation 
of  the  "next  shot”  target.  The  "next  shot"  target  is  where  the  PDT  box  will  move  to  upon  the  next  quick 
step  command  by  the  pilot. 

3.1.23.3  Expanded  Field  of  View  Display 

The  MCS  displays  incorporate  a  unique  capability  called  the  Expanded  Field  of  View  (EFOV)  display 
concept.  The  EFOV  concept  provides  the  pilot  with  the  capability  to  visually  track  an  aircraft  which  is 
Within  Visual  Range  (WVR),  but  is  not  in  the  field  of  view  of  the  monitor.  An  EFOV  symbol  appears  at 
the  edge  of  the  screen  for  each  aircraft  that  is  within  5  NM  of  the  ownship.  A  detailed  description  of  these 
EFOV  symbols  and  how  they  work  is  presented  in  section  3.1.2.3.3.1  of  this  document. 

The  MCS  display  has  three  different  display  views  available  at  any  time  during  the  simulation  that  are 
toggled  by  pressing  forward  on  the  castle  switch  located  on  the  stick  grip.  The  first  view  is  the  cockpit 
2000  main  instrument  panel  described  in  section  3.1 .2.3.1.  The  second  view  (Fig.  3-10)  is  the  full  EFOV 
display.  The  EFOV  display  consists  of  EFOV  symbols  and  a  generic  sky/earth  grid  with  HUD'  overlay. 

The  third  view  (Fig.  3-1 1)  is  a  split  screen  of  the  EFOV  display  on  top  and  three  MPDs  from  the  main 
instrument  panel  placed  at  the  bottom  of  the  monitor. 


3-15 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-01 


Final  Report 
3.  TRACE  Simulation 


Fig.  3-11:  Split  EFOV/HDD  View 
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3. 1.2. 3. 3. 1  EFOV  Symbol 

The  EFOV  symbol  appears  on  the  monitor  when  a  WVR  aircraft  is  not  in  the  field  of  view  of  the  monitor. 
Fig.  3-12  defines  the  different  parts  of  the  EFOV  display  circles.  The  EFOV  symbol  travels  around  the 
outside  edge  of  the  monitor  field  of  view.  The  symbol  is  drawn  in  the  appropriate  roll  plane  of  the  target. 
The  EFOV  symbol  incorporates  a  sky/earth  background  with  the  target  and  other  essential  cues.  If  the 
target  is  below  ownship,  the  ground  will  show  as  the  background.  If  the  target  is  above  ownship  the  sky 
wifi  show  as  the  background.  The  EFOV  symbol  varies  its  size  based  upon  the  range  from  ownship  to 
target.  The  closer  the  target  is  to  ownship  the  larger  the  EFOV  symbol  will  be.  This  also  can  provide  the 
pilot  with  range  rates. 


Target  Nose  On- 


Target  At  12  O'Clock 

(in  field  of  view) 


Aspect 
(Aircraft  Planform) 


Target  Nose 
Position  _ 

.  ■  Target  Nose 

and  |  90°  off 

Nose  On  Angle 
Rate 


Left  Analog  Bar 

Range  in  nm 


Instantaneous 
Field  of  View 


Right  Analog  Bar 


Beam 


Target  Flight  Path  Ribbon 


Target  Nose 
180°  Off 


Target  at  6  O'Clock 


Fig.  3-12  EFOV  Symbol  Definitions 


The  EFOV  symbol  is  not  displayed  if  the  target  is  masked  by  the  ownship.  That  is  if  the  target  is  beneath 
the  belly  of  the  ownship  the  EFOV  symbol  would  not  be  displayed  since  the  pilot  would  physically  be 
unable  to  see  the  target. 

Multiple  EFOV  symbols  are  displayed  when  required.  If  multiple  targets  are  in  the  same  roll  plane  the 
EFOV  symbols  are  overlaid  with  a  slight  offset.  The  EFOV  symbols  are  prioritized  by  range  when  overlaid 
except  the  PDT  which  would  always  be  on  top.  If  an  EFOV  symbol  contains  the  PDT  then  the  outline  of 
the  circle  is  color  coded  red. 


Left  Analog  Bar:  The  target  nose  position  analog  bar  on  the  left  side  denotes  the  position  of  the  target's 
nose  relative  to  ownship:  when  the  bar  is  at  the  bottom  (i.e.,  little  to  no  bar)  it  means  the  target’s  nose  is  180 
degrees  off  or  tail  on  to  you.  If  the  bar  is  half  way,  it  means  the  target’s  nose  is  90  degrees  off.  When  the 
bar  is  full  or  all  the  way  at  the  top,  the  target’s  nose  is  pointed  at  you.  As  the  bar  moves  up  or  down,  the 
rate  at  which  the  bar  moves  gives  the  target’s  nose  rate. 

Right  Analog  Bar:  The  target  relative  position  analog  bar  on  the  right  side  shows  the  target  position 
relative  to  ownship's  nose.  If  the  bar  is  full  or  at  the  bottom,  the  target  is  at  your  .6  o'clock.  When  the  bar  is 
halfway  or  at  the  beam  position,  the  target  is  abeam  at  9  or  3  o'clock.  If  the  bar  is  small  or  approaching  the 
top,  the  target  is  approaching  the  instantaneous  field  of  view  (i.e.,  the  monitor  screen)  or  the  front  field  of 
view.  As  the  bar  hits  the  instantaneous  field  of  view  marker  the  EFOV  circle  will  disappear  from  around 
the  target  and  the  target  will  be  free  of  the  EFOV  symbol  until  it  moves  beyond  the  field  of  view  of  the 
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monitor  again.  The  rate  at  which  the  bar  moves  gives  the  pilot  nose  rate.  (The  phantom  bar  is  only  shown 
as  representative  bar  travel  and  does  not  appear  on  the  actual  display.) 

Instantaneous  Field  of  View  Mark:  The  instantaneous  field  of  view  mark  is  located  at  the  17  1/2  degree 
point  up  the  target  relative  position  analog  bar  for  a  29"  monitor.  This  mark  represents  the  point  at  which 
the  target  will  appear  on  the  monitor. 

Range  Display:  Gives  the  range  between  the  ownship  and  the  target.  It  can  also  give  rough  closure  rates  to 
the  pilot  via  range  changes. 

Aspect/Aircraft  Planform:  The  aircraft  view  or  picture  of  the  aircraft  gives  the  actual  orientation  of  the 
target  if  the  pilot  were  to  turn  his  head  and  look  at  the  aircraft.  The  target’s  attitude  would  let  the  pilot  know 
the  target's  aspect,  shows  the  target  going  away  if  the  pilot  sees  the  tail  and  closing  or  threatening  him  if  he 
sees  the  target's  nose,  etc.  The  display  has  a  sizing  model  which  shows  the  targets  actual  size  based  on 
range. 

Target  Flight  Path  Ribbon:  The  target  flight  path  ribbon  indicates  the  target’s  past  flight  path,  this  also 
shows  on  the  monitor  front  field  of  view,  since  the  pilot  uses  the  target's  flight  path  as  the  primary  reference 
to  perform  his  basic  fighter  maneuvers  against  that  target  during  close-in  combat. 

3 A. 23 3 2  Split  EFOV/HDD  View 

The  split  EFOV/HDD  view  (Fig.  3-11)  provides  the  pilot  with  a  split  screen  of  the  full  EFOV  view,  three 
MPDs  from  the  Cockpit  2000  display,  a  basic  set  of  flight  instruments,  and  warning  lights.  This  single 
display  format  provides  the  pilot  with  sufficient  information  to  perform  typical  air-to-air  combat  tasks.  This 
display  format  would  normally  be  selected  unless  the  pilot  desired  more  detailed  information  from  the  full 
EFOV  view  or  Cockpit  2000  display. 

The  out  the  window  EFOV  view  portion  of  the  display  provides  the  same  capabilities  as  the  full  EFOV 
view.  However,  the  field  of  view  of  the  EFOV  portion  of  the  display  is  reduced  in  the  vertical  plane  from 
30  to  22  degrees  by  dropping  4  degrees  from  both  the  top  and  bottom  edges  of  the  full  EFOV  view.  This 
window  is  then  translated  vertically  up  in  order  to  make  room  for  the  MPDs  at  the  bottom. 

The  MPDs  in  the  HDD  portion  of  the  display  provide  the  same  capabilities  as  the  MPDs  in  the  Cockpit 
2000  display.  However,  the  size  of  the  MPDs  is  reduced  to  allow  them  to  fit  in  the  bottom  portion  of  the 
split  screen  display.  Also  added  to  the  HDD  portion  of  the  display  were  a  basic  set  of  instruments  and 
warning  lights.  The  instruments  that  are  represented  include  ADI,  Airspeed,  Altitude  and  Vertical  Velocity 
indicators.  The  warning  lights  that  are  functional  are  AI,  SAM,  Bingo  fuel,  Joker  fuel,  Low  Altitude,  Chaff 
release,  Flare  release,  and  Speed  Brake  extension. 

3 A 3333  Full  EFOV  View 

The  objective  of  the  full  EFOV  view  (Fig.  3-10)  is  to  provide  the  pilot  with  the  required  situational 
awareness  to  fly  and  fight  using  a  manned  combat  station  display  on  a  29"  monitor  with  a  field  of  view 
having  35  degrees  in  azimuth  and  30  degrees  in  pitch  (Fig.  3-13).  The  full  EFOV  view  consists  of 

1)  an  out  the  window  view  with  a  earth  grid  and  blue  sky, 

2)  HUD  symbology  overlaid  on  the  out  the  window  view, 

3)  moving  models  of  aircraft  and  missiles  when  in  the  field  of  view  of  the  29"  monitor, 

4)  gun  tracers,  and 

5)  the  EFOV  symbol. 

The  EFOV  symbol  provides  the  pilot  information  on  other  aircraft  outside  of  the  field  of  view  of  the 
monitor  display,  but  which  would  be  in  the  field  of  view  in  a  full  360°  field-of-view  dome. 
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Fig.  3-13  EFOV  Field  of  View 


3.1.2.3.4  HOTAS 

The  F-15E  stick  and  throttle  grips  (Fig.  3-14)  are  used  to  provide  the  switchology  needed  for  control  of  the 
simulated  aircraft  systems.  They  provide  the  pilot  immediate  access  to  control  of  the  displays  when  it's  not 
appropriate  to  use  the  bezel  push-button. 


Stick  Grip  Throttle  Grip 

Functions _ Functions 

Fig.  3-14  F-15E  HOTAS 
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3 . 1.2.3. 4. 1  Flight  Controls 

The  center  control  stick  and  throttles  provide  aircraft  control  as  in  the  F-15.  Rudder  pedals  are  not 
functional. 

3. 1.2. 3.4.2  HOTAS  Switchology 
3. 1 .23.4.2. 1  Throttle  Controls 

This  section  describes  the  throttle  switch  functions  as  depicted  in  Fig.  3-15. 


Countermeasures  Dispense  (CMD)  Switch  -  This  three-position  toggle  switch  is  spring-loaded  to  (center) 
OFF.  Pushing  down  commands  on  flare  to  be  dispensed  program. 

Target  Designator  Control  (TDC)  -  The  TDC  is  an  isometric  positioning  device  with  a  depressable  action 
switch.  It  moves  the  acquisition  cursors  left-right  and  up-down  on  the  A/A  Sensor  Display  format  at  a  rate 
proportional  to  the  amount  of  force  applied. 

When  the  TDC  is  pressed  with  the  cursors  on  one  of  the  perimeter  options  on  a  display,  that  option  is 
commanded  as  if  the  push-button  next  to  it  were  pressed. 

The  TDC  can  be  used  to  change  a  display’s  range  scale  by  moving  the  cursors  to  the  top  or  bottom  of  the 
display  causing  the  range  to  "bump"  to  the  next  value  in  that  direction.  The  TDC  is  also  used  to  maneuver 
the  cursor  for  cursor  capturing  targets. 

Right  Multi-Function  Switch  (Coolie)  -  The  Coolie  is  a  four  position  switch.  Clicking  up  for  less  than 
one  second  quick  steps  the  PDT  to  the  Next  Shot  target  (if  one  exists). 

Speed  Brake  Switch  -  This  is  also  a  three-position  switch.  The  forward  position  is  retract,  the  center 
position  is  hold,  and  the  aft  position  is  extend.  The  switch  will  remain  in  any  selected  position.  If  the  Angle 
of  Attack  (AOA)  is  above  25  units,  the  speed  brake  will  not  extend  when  selected.  It  will  automatically 
retract  when  AOA  increases  through  25  units.  When  AOA  is  reduced,  the  speed  brake  will  automatically 
extend,  provided  that  the  switch  is  still  in  the  extend  position. 

This  switch  is  also  used  to  control  landing  and  takeoff  functions  in  the  simulation.  The  switch  should  be  aft 
for  landing  and  forward  for  takeoff  in  order  for  the  pseudo  gear  model  to  function  properly. 

Weapon  Select  Switch  -  This  three-position  slide  switch  primarily  controls  weapon  selection.  The  forward 
position  is  for  Medium  Range  Missiles  (MRM),  the  center  is  for  Short  Range  Missiles  (SRM),  and  the  aft 
position  selects  the  20  mm  gun. 

Gear  Switch  -  This  two  position  switch  on  the  base  of  the  throttle  is  used  to  extend  and  retract  the  landing 
gear  for  simulated  takeoff  and  landing  conditions. 

3.1.2.3.4.2.2  Stick  Controls 

This  section  describes  the  stick  switch  functions  as  depicted  in  Fig.  3-16. 

Castle  Switch  -  The  castle  switch  is  a  four- way  toggle  switch  with  a  fifth  (pressed)  position.  Left,  right, 
and  aft  movement  cycles  the  MPD/LGMPD  programmed  displays 

The  pressed  position  is  used  when  assigning  acquisition  cursors.  To  assign  the  cursors  to  a  display,  first 
depress  and  release  the  switch,  then  (within  one  second)  cycle  toward  the  intended  display.  Only  one 
display  may  have  the  assigned  cursor  at  a  time. 

Weapon  Release  Button  -  This  button  is  depressed  to  launch  missiles. 

Gun  Trigger  -  Full  action  fires  the  gun  when  in  gun  mode. 

Nose  Gear  Steering  -  This  button  will  double  the  nose  gear  steering  gain  as  long  as  it  is  held  in.  Once 
released,  steering  gains  return  to  their  normal  values. 
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Fig.  3-15  Throttle  Switches 
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3.1.2.3.5  Virtual  Battlefield  Management  System 

The  TRACE  simulation  utilized  the  Virtual  Battlefield  Management  System  (VBMS)  to  allow  the  operators 
and  spectators  to  view  the  entire  simulation  scenario  from  various  perspectives  during  individual  test  runs. 
VBMS  can  also  record  all  of  the  simulation  data  in  real-time  and  save  it  to  separate  files  to  allow  each  run 
to  be  replayed  at  a  later  time,  if  desired.  VBMS  encompasses  a  wide  variety  of  other  features  that  are  useful 
in  research  simulations,  but  those  features  will  not  be  discussed  here.  Some  example  screen  shots  of  VBMS 
can  be  seen  in  Fig.  3-17. 
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Fig.  3-17  Virtual  Battlefield  Management  System  Display 


3.1.2.4  Network  Software 

Two  separate  computers  were  used  for  the  AFRL  Network  Interface  Units  (NIUs).  A  Silicon  Graphics 
Challenge  XL  computer  which  contained  eight  R4400  200  MHz  processors,  a  SCRAMNet  card  and  a  built- 
in  Ethernet  port  was  used  as  the  main  interface  to  the  network.  It  also  contained  an  SGI  VME  E-Plex  board 
for  increased  Ethernet  connectivity.  This  board  was  connected  to  the  I/O  backplane  and  contained  eight 
individual  Ethernet  ports.  Due  to  the  direct  backplane  connection,  the  E-Plex  option  had  the  same 
capability  as  eight  separate  Ethernet  cards.  The  DASA  protocol  NIU  was  implemented  by  the  DASA  NIC 
which  was  supplied  by  DASA  and  described  in  3.2.3.  The  AFRL  interface  from  the  Encore  simulation  to 
the  NIC  was  through  SCRAMNet  to  a  process  on  the  Challenge  then  through  SCRAMNet  to  the  NIC.  The 
DIS  and  DIS-Lite  protocol  NIUs  were  implemented  completely  on  the  Challenge  and  communicated  with 
the  Encore  through  SCRAMNet.  All  the  processes  running  on  the  Challenge  were  isolated  to  a  single 
processor  using  Silicon  Graphics’  real-time  extensions  to  their  IRIX  operating  system. 

3.1.2.4.1  Encore  Interface  Software 

The  Encore  synchronously  exchanged  simulation  data  with  the  Challenge  through  SCRAMNet.  Each  frame 
of  the  simulation  the  Encore  would  read  state  data  about  the  DASA  entities  from  SCRAMNet  and  put  it  into 
DATAPOOL  and  after  the  local  models  were  done  it  would  write  state  data  about  the  ARFL  entities  into 
SCRAMNet  and  trigger  the  NIU  interface  process  on  the  Challenge  to  run.  This  software  was  independent 
of  the  network  protocol. 

3.1.2.4.2  Challenge  NIU  Software 

The  Challenge  NIU  software  implemented  the  DIS  and  DIS-Lite  protocols  using  a  version  of  Mak 
Technologies  VR-Link  that  was  modified  by  Mak  to  implement  DIS-Lite.  It  was  synchronized  with  the 
Encore  simulation  by  two  logicals  in  SCRAMNet  that  were  set  by  the  Encore.  The  first  was  set  just  after 
the  Encore  simulation  received  its  frame  interrupt  so  that  the  frame  times  could  be  synchronized  and  the 
GPS  time  of  the  start  of  the  frame  could  be  obtained.  The  second  was  set  after  the  aircraft  and  missile 
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models  were  done  to  trigger  the  network  sends  and  receives.  Conditional  compilation  was  used  to  compile 
the  DIS-Lite  version. 

3.1.2.4.3  NIC  Interface  Software 

The  AFRL  NIC  interface  software  was  implemented  on  the  Challenge  and  utilized  the  NicSimlnterface 
routines  as  described  in  chapter  3.2.3  to  communicate  with  the  NIC.  This  process  was  synchronized  with 
the  Encore  in  the  same  manner  as  the  DIS  NIU. 

3.1. 2.4.3. 1  SCRAMNet  Data  Map 

The  data  map  for  the  communications  between  the  Encore  and  the  processes  running  on  the  Challenge  was 
laid  out  as  a  large  structure  containing  arrays  of  structures  that  mirrored  the  data  needed  for  the  DIS  pdus 
that  were  used.  There  were  32  aircraft  and  weapon  fire  structures,  80  missile  and  missile  detonate 
structures,  and  a  32  by  32  array  of  radar  structures.  A  C++  class  interface,  (SimData)  to  the  structure  was 
developed  to  standardize  access  to  the  data.  The  SimData  class  was  used  in  each  of  the  protocols  interface 
processes. 
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3.2  DASA  Simulation  [DASA1 

3.2.1  Simulation  Hardware 

3.2.1.1  Dome  Simulator 

The  TRACE  simulation  used  two  of  the  Power  PC  604  RISC  (200Mhz)  processors  of  the  simulation 
computer;  one  for  the  simulation  executive  and  aircraft  and  another  one  for  the  weapon  system  simulation. 
The  simulation  executive  runs  internal  within  a  40Hz  frame,  but  provides  external  data  within  a  20Hz 
frame.  The  other  modules  are  running  synchronized  to  the  simulation-model. 

The  following  table  details  what  simulation  software  was  running,  the  rate  it  was  scheduled  to  run,  and  the 
processor  where  each  component  was  located. 


Computer  System 

Processor  # 

Software/Process 

Rate 

Power  PC  604 

1 

Sim  Executive 

40Hz 

external 

20Hz 

Power  PC  604 

1 

Weapon  System 

20Hz 

Power  PC  604 

IG  Driver 

40Hz 

Locally,  the  data  was  exchanged  via  a  fiber  optic  SCRAMNet  interface 


3.2.1.2  VLO-Cockpit  Simulator 

3.2.1.2.1  Simulation  Processors 

The  TRACE  simulation  utilized  four  Force  SPARC  CPU  cards  and  one  FORCE  CPU-40  card  for  the 
simulation  executive  and  model  processing  for  the  TRACE  simulation  tests.  The  simulation  executive  runs 
internal  within  a  40Hz  frame  but  provides  external  data  within  a  20Hz  frame.  The  other  modules  run 
synchronized  to  the  simulation-model. 

The  following  table  details  what  simulation  software  was  running,  the  rate  it  was  scheduled  to  run,  and  the 
processor  where  each  component  was  located. 


CPU  Card 

Processor  # 

Software/Process 

Rate 

SPARC-5V 

1 

Sim  Executive 

40Hz 

external 

20Hz 

SPARC-2CE 

1 

20Hz 

SPARC-2CE 

1 

CGTs 

20Hz 

CPU-40 

1 

HDD  Driver 

40Hz 

IG  Driver 

40Hz 

SPARC-5VT 

1 

Network  Interface 

variable 

3.2.1.2.2  Graphics  Computers 

The  graphics  computers  for  graphic  display  processing  are  integrated  in  the  VLO-Cockpit  simulation 
computer  on  their  own  CPU  card  as  shown  in  the  table  above.  This  computer  handles  the  cockpit  displays, 
HUDs  and  HDD’s.  This  CPU  card  is  connected  via  the  VME-Bus  over  the  Shared  Memory  architecture.  It 
drives  the  displays  with  VME-Viper-Cards  and/or  a  by  Ethernet  connected  SGI  02. 

3.2.1.2.3  Image  Generator 

With  the  VLO-Cockpit  the  TRACE  simulation  used  a  Evans  &  Sutherland  model  2000  image  generator 
(IG)  for  controlling  the  OTW  visual  scene.  The  Lake  Mead  database  was  used  and  correlated  to  that  of  the 
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Compuscene  IV  IG  used  by  the  Dome  Simulator  to  ensure  that  all  connected  simulators  in  the  network  were 
flying  over  the  same  terrain.  This  image  generator  was  configured  to  run  asynchronously  at  a  60  Hz  frame 
rate. 

3.2. 1.3  Computer  Generated  Target  (Weapon  Systems) 

This  software  package  is  designed  to  simulate  aircraft  weapon  systems  in  the  air  to  air  and  air  to  ground 
role  with  simulated  pilot  behavior  and  to  interact  with  manned  simulators  and  different  Computer  Generated 
Forces  (CGF)  via  a  network  interface. 

The  software  is  running  at  D  ASA’s  simulation  facilities  on  a  Harris  Night  Hawk  computer  and  a  SUN  Sparc 
2  workstation.  System  specific  software  is  the  connection  to  the  real  time  clock  of  the  platform  to  enable 
realtime  response  and  behavior  for  weapon  system  and  the  network  interface  and  the  installation  of  a  shared 
memory,  to  communicate  with  the  outside  world,  simulation  frame  and  weapon  system  software  are  written 
in  Fortran,  the  interface  software  partly  in  C. 

At  this  time  up  to  14  A/C  weapon  systems  including  sensors  and  armament  can  be  handled  by  the  software 
package.  This  means  that  14  participants  in  any  mix  of  internetted  simulators  and  computer  generated  A 1C 
can  interact  at  one  time.  The  software  is  wholly  parameterized,  so  changing  one  parameter  in  an  include  file 
and  recompiling  the  software  increases  the  possible  amount  of  participants.  The  only  limiting  factor  is  the 
memory  size  of  the  platform. 

Six  software  shells  can  be  identified  in  the  package  : 

•  The  simulation  frame,  connected  to  a  realtime  clock  of  the  platform,  which  controls  simulation  state  and 
realtime  scheduling 

•  The  interface  to  a  dedicated  shared  memory  region  of  the  platform,  to  communicate  with  the  outside 
world 

•  The  connection  to  a  digital  map  to  simulate  the  influence  of  terrain  on  Weapon  System  and  to  have  a 
common  terrain  data  base  with  other  participants 

•  The  decision  making  process 

•  The  maneuver  generation 

•  The  weapon  system 


The  simulation  state  can  be  controlled  in  three  different  manners.  First  by  simulation  frame  itself,  second 
by  locally  connected  simulators  via  shared  memory  interface  and  third  by  a  scenario  module  via  a  Network 
Interface  Computer,  in  which  case  the  simulation  state  will  be  controlled  globally  for  all  connected  players. 
There  are  two  ways  to  initialize  the  simulation  and  include  it  into  a  complex  internetted  scenario  simulation. 
In  the  first  case  input  data  files  are  read  in  to  set  up  weapon  system,  mission  task,  the  FLOT  (forward  line  of 
own  troops),  way  points,  armament,  expendables  and  initial  state  like  position  and  velocity.  In  the  second 
case  a  Scenario  Module  sends  via  a  Network  Interface  Computer  (NIC)  initializing  data  to  the  simulation. 

The  software  runs  in  a  50  msec  cycle  time.  How  many  weapon  systems  can  be  simulated  on  one  CPU 
depends,  beside  CPU  speed,  on  the  role  of  simulated  A/C  (the  critical  one  is  here  the  Fighter  role).  While 
one  simulation  cycle  for  one  weapon  system  including  sensors,  threat  analysis,  maneuver  logic,  autopilot 
and  A/C  systems  takes  about  4  to  4.5  msec,  every  missile  flyout  simulation  inclusive  seeker  head  operation 
needs  roughly  2  msec.  Therefore  when  8  Fighter  are  firing  a  missile  at  nearly  the  same  time,  one  run  loop 
reaches  the  frame  time  of  50  msec.  When  simulating  more  than  8  A/C  in  the  fighter  role,  they  should  be 
distributed  on  2  CPU's. 

This  holds  true  for  the  old  RISC  processors  which  are  built  into  the  Sparc  2  and  Night  Hawk.  Recently  the 
Night  Hawk  was  equipped  with  modern  Power  PC's  which  run  6  times  faster.  Taking  into  account  the 
overhead  in  the  interface  routines  used  to  exchange  data  with  the  outside  world,  first  trials  show  that  at  least 
28  Fighters,  each  firing  a  missile,  can  be  simulated  on  one  CPU. 

Several  tasks  will  be  fulfilled  by  the  interface  routines,  The  first  is  to  extract  data  from  the  simulation  and 
form  Protocol  Data  Units  (PDU's)  according  the  DASA  Protocol.  The  time  stamp  for  kinetic  PDU’s  is 
composed  of  the  internal  simulation  time  and  an  adjustment  to  the  realtime  clock.  This  is  also  done  in  the 
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interface  of  connected  simulators  and  allows  a  precise  extrapolation  of  incoming  kinetic  PDU’s  to  internal 
simulation  time.  Additionally  it  helps  to  compensate  for  occasional  overruns  of  simulation  frame  time  in  the 
dead  reckoning  algorithms. 

If  a  NIC  is  attached  to  shared  memory,  every  time  a  new  kinetic  PDU  is  sent,  the  difference  between  actual 
data  and  extrapolated  data  (if  it  exists)  is  faded  in  over  several  cycles  to  get  a  continuous  differentiable  data 
stream.  The  effect  can  be  seen  in  the  computer  generated  image  (CGI)  of  the  target  while  flying  close 
formation  with  it.  It  is  also  very  important  for  the  Radar  simulation  since  jumps,  especially  in  the  location  of 
the  target,  severely  disturb  the  derivation  of  velocity  and  acceleration  vectors  in  the  Kalman  filter  to  build 
up  radar  tracks  and  decreases  the  lock-on  range. 

3.2.2  DASA  Software  Module  Description 
3.2.2.1  DASA  Weapon  System 

An  overview  of  the  DASA  weapon  system  is  presented  in  Fig.  3-18.  The  shaded  components  were  not 
active  during  TRACE  simulations. 
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Sensors  &  Electronic  Counter  Measures 


Weapons  &  Expendables 


Fig.  3-18  Weapon  System  Components 


3.2.2.2  General  Simulation  Set  Up 

The  general  simulation  set  up  is  shown  in  Fig.  3-19.  It  describes  schematically  the  set  up  for  the  dome 
simulation.  The  set  up  for  the  VLO  -  or  Integration  -  cockpit  is  essentially  the  same. 
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The  simulation  tasks  are  distributed  on  different  CPU’s  which  exchange  data  via  “shared  memory 
The  cockpit  simulation  program  incorporates  the  network  interface  program,  the  aircraft  program  and  the 
weapon  system  interface  program  (controlling  the  initialization,  correct  cycle  time  and  termination  of  the 
weapon  system  simulation).  This  task  runs  in  a  25  msec  cycle.  The  weapon  system  simulation  program  runs 
in  a  50  msec  cycle. 

Additional  tasks  included  the  Computer  Generated  Forces  (CGF)  program  (also  running  in  a  50  msec  cycle) 
and  the  Network  Interface  Computer  (NIC)  which  connected  these  simulation  tasks  with  the  external 
participants  via  Local  Area  Network  (LAN)  or  Wide  Area  Network  (W AN). 

An  additional  task  runs  on  the  dome  simulation  computer  only,  which  is  a  program  that  extracts  data  from 
the  shared  memory  every  second.  This  data  is  used  to  produce  plots  presented  in  chapter  12  (Appendix  D  - 
Selected  Data  Recorded  During  Production  Runs  lDASA]). 

Fig.  3-19  illustrates  the  main  weapon  system  components  and  the  global  data  flow.  These  components  are: 
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■  Sensor  models  and  their  trackfile  processing 

■  Corporate  Trackfile  (CTF)  processing  including  sensor  fusion  algorithms,  threat  analysis  and 
prioritization  algorithms 

■  Man/Machine  Interface  comprising  displays  and  controls 

■  Weapons  and  fire  control  computations 

■  Countermeasures  such  as  flares,  chaff  and  jamming. 

3.2.2.2.1  Generic  Fighter  Aircraft  Model 

The  aircraft  model  used  for  TRACE  simulation  is  a  6  DOF  model  (incorporating  a  detailed  flight  control 
system,  undercarriage,  etc.).  It  is  a  design  of  a  delta  canard  configuration  originating  from  an  early  version 
for  the  European  Fighter  Aircraft. 

The  model  is  written  in  FORTRAN  and  was  used  for  the  AMS  simulation  campaign  in  1989.  Fig.  3-45 
illustrates  the  performance  of  the  aircraft  in  terms  of  its  lg  -  flight  envelope,  together  with  its  camax  -  and 
maximum  Mach  number  boundaries  (exceeding  this  structure  limit  by  more  than  5  percent  results  in  an 
aircraft  crash). 

3.2.2.2.2  Sensor  Models 

The  sensor  suite  contains 

■  A/A  Radar  of  APG  65  class 

■  Identification  Friend/Foe  (IFF)  of  MK  XII  type 

■  Radar  Warning  Receiver  (RWR) 

■  Missile  Warning  device,  producing  warnings  against  Medium  Range  Missiles  (MRM)  with 
radar  seeker  heads  and  Short  Range  Missiles  (SRM). 

The  Electronic  Counter  Measure  consists  of  a  Noise  Jammer  with  either  forward  or  backward  jamming 
capability. 

|  NOTE:  Jamming  Function  deactivated  for  TRACE  project 
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3.2.2.2.2.1  Radar /IFF 

A  block  diagram  of  the  radar  model  is  shown  in  Fig.  3-21. The  moding  and  handling  of  the  radar  is 
automated  (radar  sensor  management)  to  support  the  pilot. 
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Fig.  3-21  Block  Diagram  of  Radar  Model 
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The  following  tasks  are  carried  out: 

■  selection  of  radar  mode  (normally  Track  While  Scan,  TWS) 

■  selection  of  Pulse  Repetition  Frequency  (PRF) 

■  selection  of  scan  center,  azimuth  and  elevation  (normally  a  scan  frame  time  of  more  than  3  sec 
for  target  tracking  will  not  be  utilized,  as  only  then,  Kalman  filters  will  produce  sufficiently 
good  target  data) 

■  acquisition  of  targets 

■  tracking  of  priority  and,  if  possible,  secondary  targets 

■  a  search  scan  (“3  Scan  Mode“,  Fig.  3-36  shows  an  example  for  altitude  coverage)  is  normally 
active,  as  long  as  no  target  information  is  available  (radar  detection  or  RWR  detection) ,  or  if  in 
the  course  of  the  mission  no  prioritized  target  track  is  present  anymore. 


Main  characteristics  of  the  radar  are: 

■  Gimbal  limits 

-  azimuth  +  -  70  degrees 

-  elevation  +  -  70  degrees 

■  Stabilization 

all  search  and  track  modes  are  stabilized  with  respect  to  the  horizon. 

HUD  Acquisition  Mode  scan  is  aircraft  fixed. 

Scan  rate  is  65  degrees/sec,  except  for  Single  Target  Track  (  STT )  which  is  100  degrees/sec. 
Input  data: 

■  own  aircraft  state  vector  (position,  velocity) 

■  target  state  vector  (position,  velocity) 

■  target  radar  cross  section  (for  TRACE  runs  constant  at  5  square  meters) 

■  LOS  check  (visible  or  not  visible  due  to  terrain)  and  height  above  terrain 

■  jamming  signal,  direction  and  power  (not  active  for  TRACE  runs) 

■  MMI  or  sensor  management  inputs  determining  radar  mode  and  scan  pattern 


Output  data: 

■  radar  emission  according  to  antenna  gain  pattern 

■  radar  trackfile  data  (including  “Lock  On“  status) 

■  track  identification 


Main  modules: 

■  radar  scan  model  which  calculates  according  to  control  inputs  (azimuth,  number  of  bars,  scan 
center) 

■  scan  pattern  (horizon  stabilized  or  aircraft  fixed)  and  the  actual  beam  position 

■  radar  emissions  to  each  participant  according  to  antenna  gain  pattern  are  calculated,  if  LOS 

^  exists 

■  geometric  target  detection  and  discrimination  (including  LOS  check  for  target  visibility) 

■  detection  model  calculates  target  detection  probability  according  to  radar  mode,  radar  data  and 
height  above  terrain,  determined  by  signal  power,  main  lobe  and  side  lobe  clutter,  and  jamming 
signal  power  (according  to  antenna  main  lobe  and  side  lobe  gains  ;  measurement  errors  are 
added  to  radar  detection  values) 
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■  identification  Friend/Foe  interrogation  model 

■  radar  trackfile  processor  which  performs 

-  association  of  detections 

-  Kalman  filtering  of  associated  tracks  to  produce  trackfile  data 

-  track  identification  and  determination  of  “Lock  On“  status 

3.2.22.2.2  Radar  Warning  Receiver 

The  RWR  model  covers  360°  in  azimuth  and  +/-  90°  in  elevation  with  a  resolution  of  +/-  6°  in  azimuth  and 
+/-  12°  in  elevation.  As  an  option,  the  RWR  can  discriminate  between  friendly  and  hostile  radars. 
Detection  of  friendly  radars  will  not  be  processed  and  will  therefore  not  appear  on  the  displays. 

Fig.  3-22  presents  the  block  diagram  of  the  RWR  model.  A  special  Line  of  Sight  (LOS)  check  is  not 
necessary,  as  the  senders  of  emissions  will  perform  this  check,  and  will  therefore  not  send  out  a  radar 
emission  if  LOS  is  obscured. 
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Fig.  3-22  Block  Diagram  of  Radar  Warning  Model 


Input  data: 

■  own  aircraft  state  vector 

■  target  state  vector 

■  target  radar  emission 
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Output  data: 

■  trackfile  data  (direction  to  emitter) 


Main  modules: 

■  “In  Field  of  View“  calculation;  i.e.  can  emission  be  detected  by  available  sensor  field  of  view 

■  detection  model;  detection  will  occur,  if  predefined  signal  to  noise  level  of  detector  is 
exceeded;  measurement  errors  are  added  to  RWR  detections 

■  radar  warning  trackfile  processor  which  performs 

-  association  of  detections 

-  Kalman  filtering  of  associated  tracks  to  produce  trackfile  data 

3.22223  Missile  Warner 

Presently,  the  generic  weapon  system  has  no  model  for  a  missile  warning  device.  The  warnings  presented 
in  the  displays  are  derived  from  purely  geometric  considerations,  and,  in  case  of  MRM,  also  missile  status  ( 
i.e.  is  missile  seeker  head  searching  or  tracking  a  target ). 

The  method  is  shown  in  Fig.  3-23. 

The  present  range  values  are: 

■  MRM:  10  km 

■  SRM:  5  km. 

3.2.2.23  Weapons  and  Expendables 

The  gun  model  provided  by  Air  Force  Research  Laboratory  was  not  incorporated  at  DASA  because  the 
necessary  software  changes  in  the  Head  Up  display  could  not  be  incorporated  in  time  for  the  production 
runs  and  the  gun  was  considered  to  be  a  secondary  weapon 

The  weapon  system  contains: 

■  Generic  Medium  Range  Missile  (MRM),  AMRAAM  type 

■  Generic  Short  Range  Missile  (SRM),  AIM  9L  type 

■  Gun,  Mauser  MK  27  type 

A  total  of  8  missiles  can  be  carried,  any  mix  of  MRM  and  SRM  is  possible. 
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Fig.  3-23  Missile  Warning  Criteria 

The  expendables  on  board  are: 

■  Flares  against  SRM 

■  Chaff  against  MRM 

Flares  and  chaff  deployment  is  done  automatically  by  the  system.  A  more  detailed  description  of  flare  and 
chaff  drop  will  be  given  later. 

|  NOTE:  Chaff  is  not  available  in  the  TRACE  project 
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3.2.2.23. 1  Medium  Range  Missile 

The  block  diagram  of  the  Medium  Range  Missile  is  shown  in  Fig.  3-24.  The  seeker  head  used  in  TRACE 
is  not  susceptible  to  chaff.  The  seeker  head  lock  on  range  is  calculated  purely  by  table  look  up,  depending 
only  on  aspect  and  elevation  of  the  missile  to  the  target. 

A  LOS  check  between  target  and  missile  is  made  as  soon  as  the  seeker  head  has  lock  on  to  target,  height 
above  terrain  is  continuously  checked  throughout  the  flight. 


Input  data: 

■  own  aircraft  state  vector  (determines  missile  initial  conditions  at  time  of  firing) 

■  radar  trackfile  data  (measured  target  state  vector) 

■  target  state  vector  and  target  radar  cross  section  (RCS  for  TRACE  runs  not  applicable) 

■  chaff  state  vector  and  radar  cross  section  (not  applicable  for  TRACE  runs) 

■  LOS  check  and  height  above  terrain. 


Output  data: 

■  missile  state  vector 

■  missile  event  flags  describing  its  status  (e.g.  midcourse  guidance  phase,  autonomous  phase,  hit 
or  miss  and  termination  cause  at  end  of  flight,  i.e.  failure  case  if  miss  has  occurred) 


Main  modules: 

■  uplink  model  for  midcourse  guidance  phase  (during  this  phase,  the  measured  target  data  is 
transmitted  to  the  missile:  radar  “Lock  Breaks"  during  this  phase  will  initiate  extrapolation 
routines  to  fill  the  track  loss  gap) 

■  active  radar  seeker  head  (at  predefined  range  to  target  ("hand  over"),  the  missile  will  acquire 
the  target  with  its  own  seeker  head  and  become  autonomous;  at  this  stage,  target  state  vector, 
target  radar  cross  section  and,  if  present,  chaff  state  vector  and  chaff  radar  cross  section  will  be 
the  required  input  data) 

■  guidance  law  (which  differs  for  midcourse  guidance  phase  and  autonomous  phase) 

■  aerodynamics,  thrust  and  mass  model  determined  by  missile  performance  data 

■  flight  path  integration 

■  miss  distance  calculation 

■  hit  or  miss  assessment. 

3.2.2.23.2  Short  Range  Missile 

The  block  diagram  of  the  Short  Range  missile  is  shown  in  Fig.  3-25.  LOS  checks  and  height  above  terrain 

are  performed  throughout  its  flight. 

Input  data: 

■  own  aircraft  state  vector 

■  target  state  vector 

■  either  throttle  position  and  fuel  flow  (if  IR  emission  is  calculated  on  missile  side)  or  IR 
emission  of  target 

■  flare  state  vector  and  flare  emissions  (if  flares  have  been  dropped) 

■  LOS  check  and  height  above  terrain. 


Output  data: 

■  missile  state  vector 
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missile  event  flags,  defining  the  status  of  the  missile,  together  with  flags  indicating  termination 
cause. 


Fig.  3-24  Block  Diagram  of  Medium  Range  Missile  Model 
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Fig.  3-25  Block  Diagram  of  Short  Range  Missile  Model 


Main  modules: 

■  Infra  Red  seeker  head  model 

■  guidance  law 

■  aerodynamics,  thrust  and  mass  model 

■  flight  path  integration 

■  miss  distance  calculation 

■  hit  or  miss  assessment. 
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322233  Gun 

Fig.  3-26  depicts  the  block  diagram  of  the  gun  model. 


Fig.  3-26  Block  Diagram  of  Gun  Model 


Input  data: 

■  own  aircraft  state  vector 

■  target  state  vector  from  the  radar  trackfile;  “Single  Target  Track"  mode  of  the  radar  is 
mandatory  for  lead  computation. 

Output  data: 

■  kill  probability  of  salvo 

■  cumulated  kill  probability  for  consecutive  salvos. 

With  a  suitable  Ballistic  Model  and  the  measured  target  data,  a  Lead  Computation  is  performed.  Firing 
range  and  aiming  error  are  displayed  via  the  Head  Up  Display.  When  the  trigger  is  pulled,  a  Scoring  Model 
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is  initiated.  The  Scoring  Model  computes  hit  probability  followed  by  computation  of  kill  probability  using 
a  Vulnerability  Model  of  the  target. 

3.2.223.4  Flares 

The  block  diagram  of  the  flare  model  can  be  seen  in  Fig.  3-27. 


Fig.  3-27  Block  Diagram  of  Flare  Model 


Input  data: 

■  drop  signal  (actually  the  number  of  the  aircraft  dropping  the  flare) 

■  type  of  flare  (model  consists  of  a  number  of  different  flare  types,  characterized  mainly  by 
brightness  over  time) 

■  ignition  delay  (time  that  elapses  until  ignition  of  flare  after  deployment) 

■  random  number  for  basic  brightness  (0.8  ->  1.2). 


Output  data: 

■  flare  state  vector 

■  flare  IR  emission. 


Main  modules: 

■  calculation  of  trajectory 

■  calculation  of  burn  rate  and  mass  (where  minimum  mass  controls  termination  of  flare) 

■  calculation  of  IR  emission 

To  save  data  transfer  bandwidth,  the  flares  are  simulated  at  the  side  where  the  relevant  missile  is  simulated. 
Each  of  the  participants  had  the  flare  model  within  their  simulation.  Only  the  drop  information  of  flares  is 
transferred. 
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3.2.2.2.4  Displays  and  Controls  for  Combat  Phase 

The  display  layout  for  the  combat  phase  is  shown  in  Fig.  3-28.  Four  displays  (3  HDD  &  HUD)  are 
available. 


Fig.  3-28  Display  Layout  (Combat  Phase) 


These  are: 

■  Radar  Display 

■  Combat  (or  Tactical)  Display 

■  Corporate  Trackfile  Indicator  (CTI)  (or  Horizontal  Situation)  Display 

■  Head  Up  Display. 

3. 2.2,2 A.  1  Radar  Display 

The  display  (Fig.  3-29)  presents  its  target  information  in  range  versus  azimuth  (+  70  to  -  70  degrees). 
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- Radar  Mode 

Display  Range 


Display  Buttons  can  only  be 
operated  in  Dome  Cockpit 


up  off  Radar 

- J  1 - 1  1 - '  1 - '  - 1  1 - 1  ON  /  OF 

'  \  1  /  >  y"  ™ ""  N  - \  S'  “> 

DWN  ON 

^  J  J  l J  l 


Scan  Width 
Bars 


Manual  Default  Scan 


ON /OFF 


Target  Symbols 

★ 

red  — >  Foe 

red  — >  Foe 

Priority  Track  £) 

yellow  — >  unknown  or  neutral 

★ 

blue  — >  Friend  ^ 

blue  — >  Friend 

Fig.  3-29  Radar  Display  Symbology 


It  presents  flight  information  such  as 

■  Mach  number  (left  upper  comer) 

■  Heading  (upper  middle) 

M  Barometric  Altitude  (right  upper  comer) 

M  Pitch  ladder  (horizon  line  ->  green,  sky  blue,  earth  brown). 
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On  the  left  side  range  scaling,  radar  mode  and  number  of  bars  are  presented.  On  the  lower  left  side 
information  about  scan  width  is  shown. 

For  definitions  of  azimuth  coverage  and  elevation  coverage  of  radar  scan  pattern  see  Fig.  3-37. 

The  notation  of  “AUT“  below  each  of  this  information  displays  means  that  these  parameters  have  been  set 
automatically  by  the  radar  sensor  management. 

The  present  radar  scan  width  and  its  horizontal  position  relative  to  the  aircraft  nose  is  shown  by  two 
triangles. 

The  target  symbols  used  are  shown  in  the  insert  below  the  radar  display. 

These  symbols  are: 

■  Red  star  — : >  Priority  Track  “Foe44 

■  Blue  star  -->  Priority  Track  “Friend44 

(  Prioritization  algorithms  will  not  prioritize  friendly  tracks;  however, 
manual  inputs,  described  later,  can  also  prioritize  friendly  tracks) 

■  Red  triangle  — >  tracks  identified  as  “Foes44 

M  Yellow  squares  -->  tracks  “not  yet  identified44  or  “neutral44 

■  Blue  circles  ~>  tracks  identified  as  “Friends'4. 

The  target  symbols  carry  information,  which  are: 

■  on  the  left  side  Mach  number  (3  digits:  e.g.  125  means  Ma=  1.25)  and 

■  on  the  right  side  target  altitude  (in  1000  ft  units). 

The  radar  will  normally  be  off  and  can  be  switched  on 

■  in  the  dome  cockpit  by  the  display  button  shown  in  Fig.  3-29; 

■  in  the  VLO-cockpit  by  button  No.  7  on  the  control  panel  (see  Fig.  3-44). 

If  the  radar  is  switched  on,  a  readout  of  radar  altimeter  is  presented  in  the  lower  right  comer. 

|  NOTE:  Display  buttons  in  the  VLO-cockpit  are  not  operable 

The  display  buttons  in  the  dome  cockpit  allow  manual  changes  to  scan  pattern  parameters,  radar  mode  and 
range  scale  setting. 

This  can  be  done  by  pushing  the  relevant  “UP“  or  “DWN“  button;  e.g.  pushing  the  “UP44  button  for  bar 
setting  would  change  the  bar  setting  from  2  to  4  bars,  the  notation  “AUT“  would  change  into  “MAN44.  The 
sensor  management  would  then  accept  this  as  a  manual  input  and  would  keep  this  bar  setting  from  then  on. 
The  same  is  true  for  radar  mode,  scan  width  (azimuth  coverage)  or  range  scale  setting. 

Fig.  3-41  illustrates  this  as  a  “MANUAL  OVERRIDE44  to  the  sensor  control. 

A  return  to  automatic  mode  can  be  done  for 

■  individual  settings,  by  pressing  the  “lauto44  switch  and  the  “UP44  or  4‘DWN“  button  of  the  desired 
parameter 

■  a  complete  return  to  automatic  mode,  by  simply  pressing  the  “lnorrn44  switch. 

The  following  manual  inputs  to  the  sensor  management  can  be  made.  These  inputs  are: 

■  Single  Target  Track  (STT)  on  priority  track. 

This  can  be  done  by  pressing  the  “STT“  button  on  the  top  of  the  throttle  (see  Fig.  3-42,  “Throttle 
Controls44). 
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NOTE:  If  a  “Lock  Break“  occurs ,  the  system  will  change  to  “SRA“  (Short  Range  Acquisition) 
mode .  IfTWS  is  wanted ,  the  STT  button  has  to  be  pressed  again.  If  left  in  SRA  mode,  the  system 
will ,  if  target  is  reacquired \  return  to  STT. 

■  HUD  Acquisition  Mode  (HUDAC) 

HUDAC  mode  can  be  selected,  if  the  relevant  button  on  the  top  of  the  throttle  is  pressed  (  Fig.  3-42). 
The  HUDAC  mode  will  be  shown  on  the  radar  display  by  a  blinking  “HUDAC“  insert  (see  Fig.  3-40). 

NOTE:  The  system  will  do  STT  on  the  first  target  acquired.  The  target  can  be  rejected  by  the 
button  on  the  top  of  the  stick  (see  Fig.  3-43  Stick  Controls).  The  system  will  then  return  to 
HUDAC  mode.  A  return  to  automatic  sensor  management  will  happen,  if  the  HUDAC  button  is 
pressed  again. 

NOTE:  If  in  HUDAC  mode  a  friendly  target  is  acquired,  this  target  will  automatically  become  the 
priority  target  and  will  be  transferred  to  the  combat  display  (a  blue  star  in  the  radar  display  will 
notify  the  operator  that  this  is  a  “friendly  “  target  track). 

■  Manual  Default  Scan 

Should,  by  any  reason,  the  “3  Scan  Mode“  be  considered  inappropriate  (this  scan  mode  is  the  normal 
search  scan  commanded  by  the  Sensor  Management,  if  there  are  no  more  tracks  in  the  CTF  or  no 
priority  track;  an  example  for  altitude  coverage  is  shown  in  Fig.  3-37),  a  “Manual  Default  Scan“  can  be 
activated.  An  example  of  the  altitude  coverage  can  be  seen  in  Fig.  3-38.  This  scan  mode  is  visualized 
on  the  radar  display  by  a  blinking  “MAN  DEF“  (see  Fig.  3-39). 

This  scan  mode  can  be  activated 

■  in  the  dome  cockpit  by  the  relevant  display  buttons  (Fig.  3-29); 

■  in  the  VLO-cockpit  by  button  No.  5  on  the  control  panel  (Fig.  3-44),  ON  /  OFF  function. 

These  inputs  are  illustrated  as  “MANUAL  INPUTS“  to  the  sensor  management  in  Fig.  3-41. 

3.2.22.4.2  Combat  (Tactical)  Display 

As  in  the  radar  display,  the  combat  display  presents  its  target  information  in  azimuth  versus  range. 

In  Fig.  3-30,  the  same  situation  regarding  targets  as  in  the  radar  display  is  shown. 

The  combat  display  has  no  pitch  ladder,  only  bank  angle  is  presented  via  a  roll  marker.  Pitch  attitude 
information  is  given  by  a  digital  readout  close  to  the  roll  marker  (in  10  degrees  units). 

The  priority  target  is  denoted  by  a  red  star,  the  secondary  targets  are  shown  as  red  triangles.  Target  altitude 
(1000  ft  units)  is  written  on  the  right  side  of  each  target  symbol  with  Mach  number  on  the  left  side,  similar 
to  the  radar  display. 

The  present  software  status  allows  the  display  of  up  to  4  “Lock  On“  target  tracks.  These  tracks  are  selected 
by  a  prioritization  algorithm  which  determines  the 

■  priority  target  track  and 

■  up  to  3  next  ranking  target  tracks. 


NOTE:  As  long  as  “ aggressive  “  tracks  (i.e.  radar  tracks  with  associated  RWR-tracks  or  active 
RWR-tracks)  are  present,  these  tracks  are  of  higher  priority  than  “nonaggressive“  tracks. 

“Lock  On“  tracks  are  those  tracks,  where  the  full  target  state  is  known,  i.e.  position  and  velocity  vector. 

Tracks  identified  as  friendly  are  not  processed  by  the  prioritization  algorithm  and  will  therefore  not  appear 
in  the  combat  display.  This  will  prevent  unintentional  firings  on  own  forces.  However,  using  manual 
inputs,  which  will  be  discussed  later,  tracks  identified  as  own  forces  can  be  transferred  to  the  combat 
display. 

Manual  Prioritization: 


3-45 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc. -No.:  Dasa-S-R- 1775-01 


Final  Report 
3.  TRACE  Simulation 


Priority  can  be  changed  via  manual  input.  This  is  done  via  the  button  on  the  top  of  the  throttle  (see  Fig.  3- 
42). 

By  pressing  this  button  the  automatic  prioritization  algorithm  will  be  interrupted  and  replaced  by  the  manual 
mode.  Any  “Lock  On“  radar  track  or  active  RWR  track  in  the  “Corporate  Track  File“  (CTF;  a  trackfile 
combining  the  information  of  the  individual  sensor  trackfiles  -  Radar  and  RWR)  can  be  selected  by  stepping 
from  one  eligible  track  to  the  next  by  pressing  the  button.  This  can  best  be  observed  on  the  third  Head 
Down  Display  (CTI  Display,  which  will  be  described  next).  This  display  contains  all  tracks  (radar  tracks  - 
active  or  extrapolating  and  RWR  tracks  -  active  or  extrapolating). 

NOTE:  With  this  manual  input  also  tracks  of  own  force  can  be  prioritized  and  thereby  transferred  to 
the  combat  display . 
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Indication  for  MANUAL  PRIORISATION 


SECONDARY  Target^ 
(  with  MRMlfred  upon  ) 


612  KTS  1.67  M  055  MAN|  34560  FT 


SECONDARY  Target 


[arget 

with  Deignator 


Pitch  Angle 
Roll  Marker 


85  .  20 


85  19 


125  dj  23 


Own  MRNi  Ranges 
[AX1.RMKX2,  RMIN  ) 


i  n  PRIO  Target  MRM  Ranges 

'  0  (  RMAXU  RMAX2,  RMIN  ) 


MRM  Warning 


A/A  Radar  Warning 


SAM  Radar  Warning 

dashed :  surveillance  mode 
solid :  track  mode 
\l  solid  &  blinking  :  terminal 
kV  phase 


SRM  GUN 


un  Rounds 


remaining 


SRM  Warning 
blinking  red  dot 


Fuel  remaining 


MRM 

(  blue  ~  selected  ) 


/  2ndresp.  6  th  MRM 


(  green  =  not  selected  )  1st  resp.  5l  MRM 


“Time  to  Guide” 
“Time  to  Hit” 


Fig.  3-30  Combat  Display  Symbology  (  MRM  selected  ) 
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In  the  Manual  Prioritization  Mode  only  the  priority  target  track  is  selected,  the  algorithm  for  secondary 
tracks  will  be  still  effective. 

The  Manual  Prioritization  Mode  is  shown  on  the  combat  display  by  the  insert  “MAN“  on  the  upper  right 
side. 

This  manual  mode  can  be  reset  by  a  button  on  the  top  of  the  stick  (see  Fig.  3-43  Stick  Controls). 


Target  Reject: 

It  is  also  possible  to  reject  the  present  priority  target  track  via  a  button  on  the  stick  top 

The  rejected  tracks  get  a  “reject  flag“  and  will  no  longer  be  processed  in  the  prioritization  algorithms.  If 
Manual  Prioritization  is  selected,  these  flags  are  canceled  and  after  an  eventual  return  to  Automatic 
Prioritization,  these  tracks  will  again  be  processed. 


NOTE:  The  radar  scan  will  normally  be  centered  on  the  priority  track.  If  the  priority  track  is 
outside  of  the  radar  gimbal  limit,  it  will  be  parked  at  the  edge  of  the  gimbal  limit.  To  center  the 
radar  scan  to  any  other  than  the  present  priority  track use  “Manual  Prioritization  “  or  “Target 
Reject 

Fig.  3-41  illustrates  these  actions  as  “MANUAL  INPUTS44  to  Prioritization  Algorithms. 

For  the  priority  target,  own  missile  ranges  are  shown.  These  ranges  are  presented  in  blue. 

Also,  the  missile  ranges  of  the  priority  target  against  own  aircraft  are  presented  (assumption  is,  that  target 
has  the  same  missile  type  as  own  ship).  These  ranges  are  shown  in  red. 

Three  missile  range  indications  are  displayed  for  MRM.  These  are: 

■  RMAX1  missile  range, 

if  target  continues  with  present  heading  and  speed  then  performs  a  3g  turn  away  when  missile 
range  to  target  is  less  than  1  nautical  mile. 

■  RMAX2  missile  range, 

if  target  continues  with  present  heading  and  speed  then  performs  a  6g  turn  away  when  missile 
range  to  target  is  less  than  10  km. 

■  RMIN  Minimum  missile  range 

Inrange  calculations  are  only  performed  and  missile  ranges  displayed  if  radar  has  “Lock  On44  to  target. 
Two  missile  range  informations  are  displayed  for  SRM.  These  are: 

■  RMAX  missile  range,  if  target  starts  a  3g  turn  away  at  missile  firing  time 

■  RMIN  Minimum  missile  range 


Own  inrange  calculations  for  SRM  are  only  performed  and  missile  ranges  displayed  if  two  conditions  are 
fulfilled: 

■  radar  “Lock  On44  to  target 

■  IR  seeker  head  of  to  be  fired  missile  has  “Target  Lock44. 


Target  Designator: 

The  priority  target  track  normally  carries  the  target  designator  (white  brackets).  The  target  designator  can 
be  stepped  to  each  target  track  on  the  combat  display  by  the  button  on  the  throttle  top  (see  Fig.  3-42). 

The  target  track  carrying  the  designator  brackets  will  be  that  target  the  missile  will  be  fired  at  (MRM  or 
SRM).  If  a  secondary  target  track  has  been  designated  and  fired  upon,  the  designator  will  automatically 
return  to  the  priority  target  track. 
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If  a  MRM  has  been  fired  on  a  secondary  target  track,  a  red  square  is  added  to  the  relevant  target  symbol. 
Weapons  Display: 

The  lower  left  side  of  the  display  shows  a  weapons  display  with  information  about  the  selected  weapon  and 
weapons  remaining. 

Weapons  Selection: 

Weapon  selection  can  be  made  via  a  three  way  switch  on  the  stick  top  (see  Fig.  3-43  Stick  Controls). 
Pressing  the  switch  forward  will  select  MRM,  pressing  it  backwards  will  select  SRM,  pressing  this  switch 
down  will  select  gun. 

The  selection  of  weapons  is  shown  on  the  combat  display  in  two  ways: 

■  White  box  on  top  of  weapons  display  shows  selected  weapon; 

■  Color  code  will  show  selected  missile 

green  :  not  selected 
blue :  selected. 

■  Display  of  gun  rounds  will  change  background  color  into  blue  and  numbers  to  white,  if  gun  is 
selected. 

After  missile  triggering,  the  activated  missile  will  turn  to  red  until  it  leaves  the  launcher.  If  missile  launch 
conditions  are  not  fulfilled  the  missile  will  return  to  its  former  blue  color. 

The  time  between  “Trigger"  and  “Launch"  is  1 .0  sec  (Launch  delay  time). 

There  is  a  minimum  time  of  1.5  sec  between  consecutive  missile  Firings. 

Permanent  squeezing  of  the  missile  trigger  will  not  cause  further  missile  launches. 

On  the  lower  right  side  information  about  fired  missiles  is  shown.  This  information  is: 

•  TIME  TO  CONTROL 

approximate  time  until  missile  seeker  head  will  have  acquired  the  target  with  own  radar  seeker  head  and 
be  autonomous.  Before  that  missile  is  in  midcourse  guidance  phase,  target  has  to  be  tracked  to  give 
updates  to  missile. 

•  TIME  TO  HIT 

approximate  time  until  missile  will  hit  the  target.  If  no  “Time  Hit“  is  shown,  it  indicates  that  fired 
missile  will  probably  not  reach  the  target. 

These  times  are  approximations  only,  which  are  calculated  with  range  to  target  at  firing  time  and 
approximations  of  missile  closing  speed  versus  time  of  missile  flight. 

NOTE 

For  MRM  no  shootlights  will  be  displayed .  Decision  to  fire  completely  up  to  the  pilot. 

For  SRM  shootlights  are  displayed  as  soon  as  target  is  insideRMAX  and  IR  seeker  head  has  “Lock“ 
on  target. 

The  weapons  display  also  contains  information  about  remaining  fuel  (in  kg).  Background  of  fuel  indication 
will  turn  blue  if  “BINGO"  fuel  is  reached  (600  kg);  and  red  if  “RTB"  fuel  is  reached  (400  kg). 

RWR  Display: 

Finally,  a  RWR  display  is  integrated  into  the  combat  display,  where  the  contents  of  the  RWR  trackfile,  the 
surface  to  air  missile  (SAM)  radar  warnings,  the  MRM  warnings  and  the  SRM  IR  warnings  are  presented. 
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■  Yellow  strobes  : 

Indication  of  SAM  radar  warnings 

■  Red  triangle : 

Indication  of  MRM  warnings  displaying  the  direction  of  the  missile  in  the  horizontal  plane 

■  Red  dot: 

Indication  of  SRM  IR  warnings. 
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I  NOTE:  There  is  no  Surface  to  Air  Missile  threat  in  TRACE 
3. 2.2.2 A. 3  CTI  - Display 

The  CTI  display  (Fig.  3-31)  presents  target  track  information  in  a  “bird’s  eye  view“  Own  aircraft  is  in  the 
center  of  the  display  (circle  with  cross). 

Also,  as  an  example,  the  target  situation  is  the  same  as  in  the  previous  displays. 

This  display  presents  the  complete  contents  of  the  “Corporate  Trackfile“.  This  also  includes  extrapolating 
target  tracks  and  RWR  information. 

Target  symbols  used  are: 

■  Red  triangles  : 

“foes“,  filled  triangles  are  “Lock  On“  radar  tracks  open  triangles  are  extrapolating  radar  tracks 

■  Blue  triangles: 

“friends44,  filled  triangles  are^Lock  On“  radar  tracks  open  triangles  are  extrapolating  radar 
tracks 

The  orientation  of  the  triangles  show  target  heading.  Altitude  difference  is  displayed  similar  to  radar  and 
combat  displays. 

The  priority  target  track  is  indicated  by  a  blue  “thomb“.  In  this  example  the  priority  track  is  associated  with 
a  RWR  track  which  is  indicated  by  the  red  line  to  the  priority  track. 

Position  of  present  radar  scan  is  presented  and  corresponds  to  the  green  triangles  in  the  radar  display. 

Radar  simbal  limits  are  also  indicated. 
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Fig.  3-31  CTI  Display  Symbology 

As  additional  information,  heading  markers  are  on  the  outer  ring.  Position  of  Airport  No.  1  and  Airport  No. 
2  is  denoted  by  green  circles. 
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A  digital  readout  for  the  range  scale  of  the  outer  ring  is  shown  in  the  upper  right  comer.  This  range  scale 
setting  is  80  nautical  miles  by  default,  it  can  be  changed  manually  by: 

■  the  display  button  in  the  dome  cockpit; 

■  the  switch  on  the  throttle  top  (see  Fig.  3-31)  in  the  VLO-cockpit. 

In  the  lower  right  comer  the  present  radar  mode  is  shown. 

Information  about  missiles  remaining  is  given  in  the  lower  left  corner  (M  =  MRM,  S  =  SRM). 

In  the  left  upper  comer,  a  time  readout  is  displayed  starting  with  00.00.00  when  the  CTI  display  is  activated 
(if  deactivated,  this  time  readout  will  be  reset  to  zero  again). 

3.2.2.2.4A  Head  Up  Display 

3.2.2.2.4.4.1  Head  Up  Display  Symbologies 

Head  Up  display  symbology  will  change  depending  upon  the  weapon  selected.  Symbology  elements  have 
been  held  to  a  minimum  for  as  little  clutter  as  possible. 

3.2.2.2.4.4.2  HUD  Symbology  for  MRM  Selection 

This  symbology  is  shown  in  Fig.  3-32;  target  situation  is  again  the  same  as  presented  in  HDD’s. 

In  the  center  of  the  HUD,  the  own  aircraft  symbol  is  positioned.  On  its  left  side,  altitude  (in  1000  ft  units 
AGL  -  Above  Ground  Level  -  indication;  over  6600  ft  AGL,  barometric  altitude  will  be  displayed)  is 
displayed.  Below  that,  Mach  number  is  presented  (if  below  “Corner  Speed“,  Indicated  Airspeed  will  be 
displayed). 

On  the  right  side,  the  own  missile  ranges  are  depicted  (with  RMAX1,  RMAX2  and  RMIN  representation), 
together  with  target  symbol  and  the  indication  of  closing  speed  and  a  digital  readout  of  range  to  target  (in 
nautical  miles). 

Spatial  direction  of  MRM  warning  is  shown  underneath  own  aircraft  symbol. 

In  the  upper  left  comer  of  the  display  an  indication  of  g-load  is  presented. 

Spatial  direction  to  target  is  represented  by  the  target  designator  symbol;  a  line  points  to  the  target  which  is 
outside  the  HUD  FOV.  Spatial  angle  to  target  is  shown  above  target  designator  (in  10  degrees  units).  The 
Target  designator  will  change  from  a  semicircle  to  a  square,  if  Manual  Prioritization  is  selected. 

Pitch  ladder  and  radar  mode  complete  the  HUD  symbology. 
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3.2.2.2.4.4.3  HUD  Symbology  for  SRM  Selection 

The  symbology  is  essentially  the  same,  except  that  the  IR  seeker  head  FOV  of  the  SRM  is  scaled  down  to  fit 
the  HUD  FOV  and  also  the  position  of  the  target  designator  symbol  is  scaled  to  the  IR  seeker  head  FOV 
(Fig.  3-33). 


Prio  Target  ( Vc  positiv ) 

( tic  marks  underneath  are  : 

Rmin  ,  Rmax2  ,  Rmaxl  ) 


Pitch  Ladder 


Range  to  Prio  Target 


g-Load 


Altitude  Kft 


i — T^T  20. 


5  * 


TWS 


*  40 


Mach  number  / 

Target  Designator  MRM  Warning 

(  Number  above  is  spatial  angle  in  full  ten  degrees  , 
with  pointer  towards  target  if  outside  of  HUD  FOV  ) 


Radar  Mode 


Fig.  3-32  HUD  Combat  Format  (  MRM  selected  ) 
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(  scaled  down  to  fit  HUD  FOV  ) 

Shoot  Lights 
( if  inside  Rmax  ) 

}] 

\ 

// 

/  j 

34*  * 
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Target  Designator 
(  scaled  to  IR  Seeker  Head  FOV ) 


Fig.  3-33  HUD  Combat  Format  (  SRM  selected ) 
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3.2.2.2.4.4A  HUD  Symbology  for  Gun  Selection 

The  HUD  shows  a  firing  condition;  gun  pipper  and  target  designator  symbol  are  aligned,  target  is  within 
maximum  and  minimum  gun  range,  STT  is  selected  (which  is  the  prerequisite  for  gun  lead  computation) 
and  shootlights  are  shown  (Fig.  3-34). 


/ 

\ 

/ 

/ 

\ 

Pipper  &  Target  Designator 

Radar  Mode 

(  STT  mandatory  for  Lead  Computation  ) 

Fig.  3-34  HUD  Combat  Format  ( GUN  selected  ) 
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3.2.2.2.4A5  HUD  Symbology  for  Navigation  Mode 

For  the  sake  of  completeness  the  navigation  format  is  also  described  (Fig.  3-35). 


Pitch  Ladder  Heading  Indication 

i  j 

I  / 


Fig.  3-35  HUD  Navigation  Format 

This  format  has  a  heading  indication  at  the  top.  The  altitude  indicator  (AGL,  resp.  Barometric  altitude  if 
over  6600  ft  AGL)  is  on  the  right  side. 

Mach  number  readout  is  shown  on  the  left  side  together  with  a  Indicated  Airspeed  band  (in  kts). 

Pitch  ladder  and  flight  path  indicators  complete  the  navigation  format. 
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NOTE:  HUD  Navigation  Mode  is  not  available  in  VLO-Cockpit 


Fig.  3-36  Radar  Scan  Pattern 
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Automatic  Default  Scans  (  ”3  Scan  Mode"  ) 

(if  not  yet  or  no  more  prioritized  track  exists;  Az  30  deg,  6  bars) 
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Fig.  3-37  Example  of  Altitude  Coverage  of  “3  Scan  Mode 
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Manual  Default  Scan 

(  Az  45  deg  ,  8  bars  ; 

activated  by  relevant  Radar  Display  buttons) 


HUDAQ  -  MODE  (  30  deg  .  8  bars  ) 

Activation  by  button  on  throttle 
at  target  detection  — >  switch  to  STT 
(  first  target  that  is  detected  ) 

SINGLE  TARGET  TRACK  (STT) 

Activation  by  button  on  throttle 
priority  track  (radar  track)  must  exist 


Fig.  3-38  Example  of  Altitude  Coverage  of  Manual  Default  Scan 
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Fig*  3-39  Indication  for  Manual  Default  Scan 

□ 

□ 

□ 

□ 

□ 
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Fig.  3-40  Indication  for  HUD  Acquisition  Mode 
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Fig.  3-41  Manual  Inputs  and  Overrides 
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Fig.  3-44  Control  Panel  of  VLO-Cockpit 
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3.2.2.2.S  Deployment  of  Expendables 

Expendables  on  board  the  aircraft  are: 

■  Flares  against  SRM 

■  Chaff  against  MRM 

|  NOTE:  Chaff  is  not  available  in  the  TRACE  project 

All  expendables  are  dropped  automatically  by  the  system. 

Flares  will  be  dropped  as  soon  as  the  IR  missile  warning  is  activated. 

Number  and  sequence  of  flares  dropped  depends  on: 

■  missile  in  forward  or  backward  hemisphere 

■  present  throttle  position 

■  approximate  range  of  missile  to  aircraft. 

At  present,  a  maximum  of  8  flares  will  be  dropped  against  each  missile. 

NOTE:  Best  results  are  achieved ,  if  flare  drop  is  accompanied  by  an  avoidance  maneuver  and 
decrease  of  throttle  setting. 
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3.2.3  Network  Interface  Computer  (NIC) 

3.2.3. 1  DASA  NIC 

The  Dasa  NIC  Computer  at  AFRL  is  comprised  of  a  Force  VMEbus  rack  connected  via  SCRAMNet  to  the 
AFRL  Simulators  and  connected  via  Ethernet  to  the  WAN  interface,  an  Ascend  Pipeline  50  ISDN  router  (2 
B-channels,  total  bandwidth  128  kbit/s).  A  block  diagram  of  the  NIC  configuration  at  AFRL  is  shown  in 
Fig.  3-46. 

The  Dasa  NIC  Computer  in  Munich  uses  a  Force  Sparc  CPU  from  the.  VLO  cockpit  simulator  which  is  also 
connected  via  SCRAMNet  to  the  VLO  cockpit  simulator,  the  Dome  cockpit  simulator  and  the  CGF 
simulator.  A  block  diagram  of  the  NIC  configuration  at  DASA  Ottobrunn  is  shown  in  Fig.  3-47. 


Fig.  3-46  DASA  NIC  Computer  configuration  at  AFRL 
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Fig.  3-47  Dasa  NIC  Computer  configuration  in  Munich 


The  data  exchange  between  the  simulators  and  the  NIC  is  accomplished  via  the  object  oriented 
NicSimlnterface  routines  depicted  below  in  detail. 

3.2.3.1.1  Dead  Reckoning 

The  main  function  of  the  NIC  is  to  determine  when  new  data  received  from  the  own  simulator  needs  to  be 
updated  to  the  other  participants  in  the  simulation  exercise.  New  entity  position  and  orientation  data  from 
the  own  simulator  (high  fidelity  model)  are  passed  to  the  Dead  Reckoning  function.  The  last  transferred 
position  and  orientation  data  are  extrapolated  to  the  time  stamp  of  the  new  data  (low  fidelity  model).  If  the 
error  between  the  low  fidelity  model  and  the  high  fidelity  model  exceeds  the  specified  threshold,  the  new 
data  is  marked  for  distribution  over  the  simulation  network.  The  important  key  here  is  that  the  new  data  is 
only  marked  for  transfer  and  inserted  or  updated  in  a  priority  list  (see  chapter  3.2.3. 1.2),  but  no  PDU  is  built 
and  output  at  this  time.  This  is  done  in  the  “bundle  PDU  package"  function  below. 

In  the  DASA  Protocol  an  enhanced  Dead  Reckoning  Algorithm  is  used.  Orientation  data  is  extrapolated 
according  to  angular  velocity  and  angular  acceleration  whereas  in  DIS  Protocol  only  first  order 
extrapolation  for  orientation  data  is  provided.  Especially  in  high  dynamic  phases  like  the  engagement  phase 
of  an  air  combat  scenario,  the  enhanced  Dead  Reckoning  Algorithm  reduces  network  bandwidth 
requirements  through  lower  update  rates. 

The  Dead  Reckoning  for  all  foreign  entities  is  done  by  the  NicSimlnterface  method  “updateNetEntities" 

(see  chapter  3.2.3. 1.2).  When  this  method  is  called  all  foreign  entities  are  extrapolated  to  the  current  time. 
Therefore,  this  method  shall  be  called  by  the  simulator  immediately  before  the  simulator  works  on  this  data. 

3.2.3.1.2  Priority  List 

All  data  from  the  own  simulator(s)  which  is  marked  for  transfer  to  the  other  participants  in  the  simulation 
exercise  are  managed  in  a  double  linked  priority  list.  The  highest  priority  data  is  found  at  the  top  of  this  list 
and  the  priority  decreases  to  the  bottom  of  the  list. 
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The  priorities  for  the  own  simulator  data  are  ascertained  either  from  the  dead  reckoning  results  (for 
kinematic  data),  from  the  importance  of  the  changed  data  or  from  the  minimum  update  rate. 

The  priority  list  is  accessed  when  PDU  packages  are  bundled  and  sent  (see  chapter  3.23.1.4). 

3.2.3.1.3  Network  Load  Control 

To  control  the  network  output  load,  the  dead  reckoning  thresholds  can  be  modified  by  the  NIC.  The 
following  initialization  parameters  are  used  to  control  the  network  output  load: 

■  lower  and  upper  limit  for  the  position  and  orientation  thresholds  for  missiles 

■  lower  and  upper  limit  for  the  position  and  orientation  threshold  for  all  other  entities  (mostly  aircraft) 

■  underload  threshold  for  output  data  rate  in  kbit/s 

■  overload  threshold  for  output  data  rate  in  kbit/s 

The  NIC  allows  separate  thresholds  for  aircraft  and  missiles.  Missile  thresholds  can  be  made  higher  than 
those  for  the  aircraft  without  reducing  the  quality  of  the  simulation.  This  again  saves  network  bandwidth 
especially  during  peak  load  phases  when  almost  everybody  is  engaged  in  an  air  fight  scenario  shooting 
missiles  almost  simultaneously  at  each  other. 

The  position  and  orientation  thresholds  are  modified  according  to  the  diagram  below. 


Fig.  3-48  Dynamic  Dead  Reckoning  Thresholds 


3.23.1.4  Bundle  PDU  Package 

Bundling  PDU’s  in  a  package  reduces  the  network  overhead  and  thus  the  network  load. 

The  bundle  PDU  package  function  accesses  the  priority  list  (see  chapter  3.23.1.2)  to  determine  the  highest 
priority  data  for  output.  PDU’s  are  built  from  the  newest  simulator  data  and  are  bundled  in  a  package  until 
the  package  is  full  or  the  priority  list  is  empty.  Finally,  the  package  is  output  to  the  simulation  network. 
Only  one  package  per  NIC  cycle  is  transferred.  The  NIC  cycle  time  is  10  msec.  Therefore,  the  maximum 
output  packet  rate  is  100  packets/s.  The  PDU  package  size  is  a  NIC  initialization  parameter.  Through  the 
definition  of  the  PDU  bundle  size,  the  maximum  network  output  load  produced  by  one  NIC  is  also  given. 
Examples  are  shown  below: 
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max  PDU 

max  network 

bundle  size 

output  load 

in  bytes 

in  kbit/s 

100 

78 

165 

128 

500 

390 

Adapting  the  maximum  NIC  network  output  load  to  the  available  network  bandwidth  will  prevent  network 
overload  resulting  in  undeterministic  packet  losses  and  packet  delay.  A  graceful  degradation  is  thus 
achieved  since  overload  conditions  are  solved  by  the  NIC  in  a  fully  deterministic  way.  If  necessary,  PDU 
output  is  delayed  by  the  NIC  but  finally  when  output,  always  the  newest  simulator  data  are  output. 

3.2.3.2  DIS-  DIS-Lite-NIC 

To  use  the  DIS-  and  additionally  DIS-Lite-protocol,  special  software  modules  were  developed  with  support 
from  the  AFRL  system  and  software  engineers.  These  were  based  on  the  most  recent  version  of  VRLink’s 
object  library  from  Mak  Technologies. 

Both  the  DIS  and  the  DIS-Lite  module  were  designed  to  run  on  a  FORCE  SPARC  CPU  and  to  drive  the 
interface  of  the  DASA  simulation. 

Following  are  some  TRACE-relevant  modifications  to  the  DIS  and  DIS-Lite  protocols  that  were  done  to 
ensure  complete  coverage  of  the  information  exchange  needed  for  some  weapon  system  aspects: 

==>  only  one  system,  one  beam,  one  target  used  in  ElectromagneticEmissionPdu 
:=>  input  radar  intensity  transmitted  rather  then  output  intensity 
=>  VLO/RaderType  DIS/SystemName  (Nr.O) 

=>  VLO/RaderMode  DIS/SystemFunction  (Nr.O)  (note:  VLO/RadarMode  is  not  actually  used) 
rr>  VLO/MissileStatus  AND  VLO/BreakCondition  for  Missiles  is  transmitted  in  DIS/DetonationResult 
=>  No  DIS/MarkingText  transmitted 
=>  VLO/Role  not  transmitted 

=>  VLO/MissileNumber  transferred  via  DIS/EntityType:Extra 
=>  VLO/Flares  are  transmitted  via  DIS/FirePdu 

=>  values  are  arbitrarily  coded  in: 

VLO/Orientation.PO  -  DIS/burst.quantity  -  number  flares 
VLO/Orientation.Pl  -  DIS/burst. warhead-  flare  type 
VLO/Orientation.P2  -  DIS/burst.fuze  -  ignition  delay 

VLO/Orientation .P3  -  DIS/burst.rate  -  light  intensity  number 


3.2.4  AFRL/VACD  Guns  Integration 

The  gun  model  provided  by  Air  Force  Research  Laboratory  was  not  incorporated  at  DASA  because  the 
necessary  software  changes  in  the  Head  Up  display  could  not  be  incorporated  in  time  for  the  production 
runs  and  the  gun  was  considered  to  be  a  secondary  weapon 


3-69 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-01 


Final  Report 
4.  TRACE  Program  Conclusions 


4.  TRACE  Program  Conclusions  [Dasa  &  AFRL1 

4.1  Lessons  Learned 

4.1.1  ISDN  Standards 

4.1.1.1  ISDN  Computer 

At  the  beginning  of  the  related  work  Dasa  provided  a  PC  based  ISDN  router  to  the  TRACE  program  as  they  have 
been  used  for  European  programs  many  times  before.  Within  the  PC  there  was  a  special  ISDN  router  card  installed 
supported  by  a  software  running  under  Novell-OS.  The  complete  setup  has  to  be  performed  under  MS-DOS. 

Configuring  these  routers  for  the  TRACE  program,  i.e.  for  connecting  US-ISDN,  resulted  in  several  problems  and  the 
support  of  the  ITK  hotline  was  insufficient.  It  cost  a  lot  of  time  and  work  to  figure  out  the  failure  roots,  especially  as 
promised  functionalities  could  not  be  set  up  at  all.  After  spending  a  great  deal  of  time  troubleshooting,  it  was  decided 
to  invest  in  a  new  and  simple  solution  using  Ascend  Pipeline  50  routers,  which  limitations  did  not  affect  the  TRACE 
program  requirements. 

Due  to  the  ITK’s  more  complex  configuration  processes,  the  following  points  should  be  considered  when  selecting  a 
network  solution: 

Installation  /Service  /Hotline 

•  Complicated  installation  process 

•  Availability  of  the  ITK  hotline  very  arbitrary 

•  Questions  concerning  IP  multicasting  (if/when  available)  could  not  be  answered  sufficiently 

•  hard  disk  availability  on  the  ITK  router  helped  in  troubleshooting  (better  than  of  Ascend  without  hard  disk.) 


Channel-Bundling 

•  problems  when  intermixing  different  versions  and  when  using  it  with  foreign  countries  (U.S.,  Switzerland, 
different  standards)  even  with  ITK*s  proprietary  protocol. 

•  No  multilink  PPP  supported  up  to  now  (see  Outlook). 

•  No  more  than  2  B-channels  will  be  supported  (in  the  near  future). 


Usability 

•  For  merely  IP  networks  the  usability  is  quite  questionable  because  you  normally  need  a  Novel  1-network  and  a 
workstation  on  it  to  handle  the  router  appropriately  -  Not  having  a  Novell(IPX)  workstation  results  in  lot  work 
arounds 

•  Update  of  S/W  through  public  domain  tool  (NWSUELL)  which  often  crashes 

•  Consistency  insufficient 

Outlook 

•  A  new  version  was  produced  in  Aug  97  called  RAR4000  (and  a  "light"  version  MPR4.0)  that  implements 
multilink  ppp  allowing  2  B-channels  to  be  bundled  over  ppp  -  which  in  turn  allows  a  2  B-channel  connection  with 
other  routers  like  Ascend.  No  more  than  2  B-channels  will  be  supported  at  that  time.  According  to  ITK  this  is  a 
problem  of  how  the  German  Telekom  supplies  slots  (a  timing  problem  ?).  The  question  is  then  how  will  router 
venders  (i.e.  Cisco)  produce  channel  bundling  over  more  then  2  B-channels  (using  the  same  German  Telekom  ) 
We  would  need  to  approve  channel  bundling  with  more  than  2  B-Channels  with  products  like  Cisco,  Ascend. 

•  No  Ascend  or  Cisco  proprietary  protocols  will  be  supported  with  RAR4000  /  MPR4.0. 
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4.1.1.2  ASTi  -  Dialogue  Communications  System 

TRACE  attempted  to  use  the  ASTi-Dialogue  system  for  its  voice  communications-link  via  the  WAN. 

This  report  contains  the  results  and  conclusions  of  the  communications-test-phase  during  March  1997. 

•  Data  Compression  Rate  /  Data  Bandwidth 

Two  compression  algorithms  are  available  with  the  ASTi-software:  standard  u-law  and  CVSD.  When  using 
standard  u-law  compression,  the  ASTi  system  requires  a  data  bandwidth  of  approx.  100  kBit/sec.,  which  is  far  too 
much  to  be  useable  within  the  TRACE- project.  The  CVSD-compression  offers  a  significantly  lower  data 
bandwidth,  approx.  40  kBit/sec.,  but  yields  a  degraded  voice  quality.  However,  the  necessary  data  bandwidth  is 
still  much  higher  than  the  theoretically  achievable  value  of  12  to  16  kBit/sec.,  which  is  a  strong  indication  of  a 
high  degree  of  system-specific  overhead. 

However,  the  CVSD-data-bandwidth  enables  the  ASTi  system  to  be  used  when  at  least  two  64-kBit-lines  are 
available  for  connecting  two  simulators. 

•  Voice  Quality 

The  overall  voice  quality  is  low,  but  readable.  Due  to  heavy  timing  problems  induced  by  the  transatlantic 
connection,  the  voice  quality  of  the  standard  u-law  compression  is  even  less  than  the  CVSD-compression. 
Distortion  is  around  10  percent,  a  high,  but  still  tolerable  value,  but  the  background  noise  of  the  system  (including 
the  quantization  noise)  is  very  high  and  makes  it  impossible,  to  wear  the  headset  over  a  longer  period  of  time. 

•  VOX-control 

The  VOX-control  did  not  work  properly  due  to  threshold  problems.  The  ASTi  system  was  constantly  sending  out 
data  packets,  which  lead  to  a  data-overflow  on  the  receiving  site.  It  was  therefore  impossible  to  establish  a  two- 
way  communication. 

•  PTT-control 

When  using  the  Press-To-Talk  control,  a  two-way  (but  half-duplex)  communications-link  had  been  able  to  be 
established. 

However,  the  Dasa-located  ASTi-system  did  not  have  the  necessary  hardware  extensions  to  enable  the  user  to 
activate  the  PTT-control  in  a  different  way  than  by  pressing  a  key  on  the  ASTi-keyboard,  which,  of  course,  is 
impossible  for  someone  in  a  simulator  cockpit. 

•  ASTi  Handling 

Due  to  the  lack  of  being  able  to  store  the  settings  made  during  a  session  and  the  quite  tedious  initialization 
sequence,  overall  handling  quality  is  poor. 

The  store-option  is  available  as  an  add-on,  but  was  not  supplied  with  the  Dasa-located  ASTi-system. 


Conclusion 

Due  to  the  limitations  and  restrictions  mentioned  above,  the  ASTi-system  in  its  current  configuration  was  not  useable 
within  the  TRACE-project. 


Alternate  Means 

Currently,  no  other  WAN-based  communication  system  was  available  for  the  TRACE  program.  The  use  of  a  separate 
telephone  line  together  with  an  analog  communications  system  is  suggested. 

4.1.13  ELSA  Vision  Video  Teleconferencing 

For  the  TRACE  Production  Runs,  it  was  planned  to  install  a  video  conferencing  system  to  support  the  effectiveness 
of  the  pilots  briefing  and  debriefing  phase. 

An  “ELSA  Vision  Video  Conferencing  System44  was  tried  to  setup  and  failed  due  to  similar  problems  as  for  the 
installation  process  of  the  PC  based  ISDN-router.  Again,  the  support  of  ELSA  for  solving  transatlantic  connection 
problems  was  insufficient.  At  least  just  a  normal  voice  connection  via  a  single  ISDN  B-channel  could  be  set  up. 

Because  this  was  not  an  objective  of  the  TRACE  program,  no  further  studies  for  getting  such  a  system  running  has 
been  performed. 
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4.1.2  Model  Fidelity  Problems 

The  following  subsections  describe  various  model  fidelity  problems  in  the  U.S.  simulation  that  lead  to  an  unfair 
advantage  to  the  U.S.  pilots  when  compared  to  the  capabilities  of  the  affected  systems  in  the  German  simulation.  The 
net  result  of  this  advantage  was  that  the  U.S.  pilots  achieved  a  greater  number  of  kills  than  the  German  pilots  in  the 
tested  scenarios.  This  mainly  degraded  the  realism  of  the  simulation  and  had  little  or  no  effect  on  the  main  purpose 
of  the  TRACE  tests  which  is  to  investigate  the  capabilities  of  different  long  haul,  networked  simulation  protocol  and 
their  potential  application  to  air  combat  simulations. 

4.1.2.1  US  Performance  Model 

The  aircraft  model  utilized  in  the  U.S.  simulation  was  an  F-15C  fighter  performance  model.  The  engine  model 
internal  to  this  F-15C  model  was  based  on  an  advanced  capability  engine.  This  had  the  result  of  giving  the  F-15C 
model  greater  performance  capability  than  that  of  a  standard  F-15C.  This  provided  the  U.S.  pilots  with  a  distinct 
performance  advantage  over  the  German  pilots  during  the  simulated  combat  scenarios. 

4.1.2.2  US  Radar  Model 

The  radar  model  utilized  in  the  U.S.  simulation  was  a  subset  of  a  complete  APG-63  radar  system.  Due  to  model 
integration  delays,  only  the  Track-While-Scan  (TWS)  mode  was  available  and  Doppler  effects  were  not  yet  included. 
The  IFF  system  was  a  simplistic  identification  model  that  returned  truth  data  for  FFN  ID  and  aircraft  type  for  all  radar 
tracks.  The  effects  of  terrain  were  also  not  incorporated  in  the  radar  model,  although  Dasa  did  provide  the  U.S.  with 
a  routine  to  determine  if  line  of  sight  between  objects  was  blocked  by  terrain.  Unfortunately,  this  capability  was  not 
able  to  be  integrated  prior  to  piloted  testing.  The  lack  of  complete  radar  model  fidelity  on  the  U.S.  side  resulted  in 
the  U.S.  pilots  having  superior  radar  detection  and  tracking  capability  than  the  German  pilots. 

4. 1.2.3  US  LOS  Checking 

As  mentioned  in  the  previous  section,  Dasa  did  provide  the  U.S.  with  software  to  determine  if  line  of  sight  between 
objects  was  blocked  by  the  terrain  in  the  Lake  Mead  database.  This  was  intended  to  be  utilized  by  both  the  radar 
model  and  missile  models  to  provide  for  a  more  realistic  simulation  of  terrain  effects  on  detection  and  tracking 
capabilities.  This  capability  was  not  able  to  be  integrated  with  the  U.S.  simulation  prior  to  piloted  testing  and 
resulted  in  the  U.S.  pilots  having  an  additional  advantage  over  the  German  pilots  due  to  the  fact  that  they  were  able  to 
track,  fire  missiles  at,  and  destroy  targets  that  should  have  been  protected  by  the  terrain. 

4.2  Recommendations 

In  Phase  I  of  the  TRACE  Program  a  network  architecture  was  defined  and  implemented  using  different  networks  and 
protocols. 

Simulation  facilities  on  opposite  sides  of  the  Atlantic  ocean  were  networked  to  conduct  integrated  research  and 
training  simulations  using  existing,  modified  and,  sometimes,  newly  developed  technology. 

The  objectives  of  the  program  were: 

•  to  perform  US  AF  and  MOD  research  into  long  haul  simulator  network  technology  by  coupling  the  simulation 
facilities  of  AFRL  and  Dasa. 

•  to  determine  feasibility  for  developing  a  common  American/German  protocol  optimized  for  Air  Force 
applications. 

•  to  conduct  simulations  showing  the  technical  capabilities/limitations  for  potential  operational  use  in  aircrew 
training. 

4.2.1"  Networking  the  Simulations 

Overall,  it  is  possible  in  general  to  network  the  simulation  facilities  over  the  transatlantic  distance.  The  following 
three  media  for  the  connection  were  surveyed  : 

•  The  ATM  line  (Asynchronous  Transfer  Mode) 

This  media  was  not  available  for  the  transatlantic  connection  and  additionally  seems  to  be  too  expensive  for  the 
TRACE  program.  No  performance  data  was  measured. 
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•  The  DSI  (Distributed  Simulation  Internet) 

A  special  connection  using  this  media  using  a  commercial  128  kbps  ISDN  was  set  up.  The, measured 
performance  data  for  the  usable  bandwidth  and  delay  times  were  poor.  The  connection  to  the  network  was  quite 
complicated  and  was  performed  during  the  TRACE  program  via  an  additional  ISDN  line.  Although  this  media, 
fiber  optic  cable,  would  provide  a  higher  bandwidth,  the  entry  lines  (i.e.  ISDN)  will  limit  the  bandwidth. 

The  service  was  unreliable  and  the  costs  for  the  required  bandwidth  were  relatively  high. 

The  response  time  of  this  media  is  insufficient. 

With  the  exception  of  the  ISDN  entry  line,  this  media  is  secure. 

This  media  is  no  longer  available  outside  the  U.S. 

•  The  ISDN-  telephone  line 

During  the  TRACE  program,  a  standard  ISDN  telephone  connection  was  established  each  time  a  test  or 
production  run  was  started.  The  German  Telekom  could  not  guarantee  that  the  connection  would  always  be  set  up 
via  transatlantic  cable,  indispensable  for  a  real-time  simulation  connection  (because  of  the  delay  times).  During 
the  entire  TRACE  program,  it  is  estimated  there  were  probably  only  one  or  two  times  a  connection  was  made  via 
satellite. 

A  fixed  telephone  line  with  a  guaranteed  use  of  the  transatlantic  cable  connection  would  be  available  but  then 
ISDN-configuration  (i.e.  channel  bundling)  is  not  ensured.  Additionally,  the  cost  is  much  higher  for  guaranteed 
transatlantic  cable  connections. 

Service  and  support  are  not  needed  and  direct  access  of  the  simulation  facilities  is  possible  which  eases  network 
handling.  The  usable  bandwidth  is  very  high,  the  delay  times  are  extremely  low  (ca.  100ms)  and  there  is  actually 
no  response  time.  Additionally,  the  costs  are  low. 

The  line  is  not  secured  at  all  and  it  is  up  to  the  user  to  perform  encryption. 

Overall  the  use  of  the  standard  ISDN  is  recommended  if  an  efficient  protocol  is  available. 

As  an  ISDN-router,  the  “Ascend  Pipeline  50“  was  a  good  and  less  expensive  alternative  to  the  PC  based  “ITK- 
ISDN-card“  which  had  been  used  by  Dasa  for  other  network  connections.  This  router’s  bandwidth  covered  the 
requirements  of  the  TRACE  program.  However,  additional  tests  are  required  to  determine  if  more  than  two  ISDN-B- 
channels  are  needed  for  higher  bandwidth  scenarios.  Likewise,  this  router  solution  does  not  provide  encryption 
functionality.  For  more  complex  scenarios  with  higher  bandwidth  needs  and  encryption  requirements,  new  products 
in  this  fast  developing  router  market  can  be  expected  in  future. 

Time  synchronization  of  the  connected  simulations  using  a  GPS-time  signal  was  efficient  and  accurate. 

The  integration  of  the  Dasa-NIC-HW  and  interface  at  AFRL  was  unproblematic  and  could  be  performed  by  AFRL 
engineers  with  some  support  by  Dasa  personnel  via  the  telephone.  The  DIS-  and  DIS-Lite  NIC  could  be  developed  at 
the  Dasa  site  efficiently,  as  long  as  the  AFRL  personnel  were  able  to  support  Dasa  with  the  most  recent  version  of  the 
object  libraries  and  additional  information  (any  help  and  manual  pages  that  were  missing). 

The  voice  link  for  cockpit  communication  could  easily  be  performed  using  a  separate  telephone  line  as  long  as  the 
cockpits  of  one  simulation  are  not  partly  friendly  to  that  of  the  connected  partner.  The  planned  “ASTI 
Communication  System"  was  not  reasonable  for  use  due  to  its  bandwidth  need  and  is  not  recommended  for  use  in 
further  networking  projects  with  limited  bandwidth. 

4.2.2  Common  American/German  Protocol  Optimized  for  Air  Force  Applications 

All  surveyed  protocols  fulfilled  the  requested  precision,  and,  with  the  exception  of  DIS-Lite,  were  usable  for  the 
developed  scenarios  with  up  to  4  vs  4  aircraft.  The  pilots  themselves  could  not  identify  which  protocol  was  being 
used  during  their  training  sessions  as  long  as  the  bandwidth  limitations  did  not  cause  positioning  errors  or  simulation 
dropouts. 

Some  modifications  to  the  DIS-protocols  had  to  be  done  in  order  to  transmit  special  air  combat  information  such  as 
dropping  flares  because  neither  the  Dasa  engineers  nor  the  AFRL  engineers  could  find  a  corresponding  data  package. 

Since  ISDN  was  the  most  reliable  and  least  expensive  networking  media  tested,  the  bandwidth  is  a  very  important 
factor  in  choosing  a  suitable  protocol.  Therefore,  the  Dasa-Protocol  was  determined  to  be  the  most  efficient  and 
predictable  protocol,  allowing  for  the  estimation  and  extrapolation  of  bandwidth  needs  for  even  more  complex 
scenarios. 
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4.2.3  Technical  Capabilities/Limitations  for  Potential  Operational  Use  in  Aircrew  Training 

All  operational  pilots  involved  in  the  testing  underlined  the  high  value  of  the  effect  of  training  tactical  maneuvers 
using  interconnected  cockpits  in  both  local  and  long  haul  networks  when  combined  with  normal  aircrew  training. 

Local  combined  simulations  to  a  simulation  cluster  increase  the  training  effect  of 

•  mission  planning  and  briefing, 

•  mission  rehearsal, 

•  tactical  maneuvering, 

•  communication, 

•  teamwork, 

•  missile  avoidance  maneuvering, 

•  debriefing. 

Connecting  such  a  simulation  cluster  to  a  distant  force  unit  would  extend  training  by  practicing  with 

•  unknown  pilots 

•  different  characters 

•  different  types  of  aircraft  (i.e.  fighter  with  bombers) 

•  more  complex  and  realistic  scenarios. 

The  international  connectivity  used  within  the  TRACE  program  enables  pilots  to  effectively  and  inexpensively 
practice  their  international  missions  under  the  above  aspects  in  a  prephase  training  mission.  Mission  plans  can  be 
developed  and  proofed  and  the  pilots  can  be  trained  on  them. 

Such  systems  can  split  necessary  pilot  training  into 

•  basics  such  as  communication  training,  which  should  mainly  not  be  done  airborne 

•  preparation  and  support  of  airborne  training,  to  ensure  best  training  effect  for  the  small  amount  of  remaining 
airborne  flight  training  time. 

•  special  maneuvers  such  as  missile  avoidance  maneuvers  which  is  very  hard  to  practice  airborne. 

Special  tools  such  as  the  Scenario  Manager,  with  its  recording  and  replay  functionality,  or  analyzers  support  the 
pilots  debriefing  by  repeating  and  visualizing  each  run,  with  the  opportunity  to  repeat  the  whole  scenario. 

Limitations  are  set  by  the  simulation  models  used.  As  the  production  runs  show,  it  is  absolutely  necessary  to  use 
models  that  are  as  realistic  as  possible.  Since  the  pilots  must  get  an  image  of  the  situation  by  interpreting  the  outputs 
of  the  sensors  such  as  radar  and  radar  warning,  the  simulation  must  provide  realistic  outputs  as  well.  Therefore,  the 
sensors  should  emulate  the  sensors  as  closely  as  possible  so  not  to  adversely  effect  training  nor  undermine  system 
acceptance 

Likewise  the  aircraft  and  missile  models  must  be  realistic  when  considering  missile  avoidance  maneuvers.  If  the 
missile  model  is  not  good  enough,  wrong  maneuvers  will  lead  to  success,  but  only  in  simulation.  The  same  applies  to 
the  aircraft  model. 

While  in  a  local  simulation  cluster  for  tactical  training  highly  realistic  or  even  original  models  of  aircraft  or  weapon 
systems  can  be  used,  long  haul  networked  simulation  cluster  requires  specific  security  measures.  A  new  technology 
has  to  be  developed  to  secure,  reduce  or  adulterate  such  data  exchange  without  reducing  the  training  effect. 

4.2.4  Conclusion 

It  was  shown  by  operational  American  and  German  pilots  that  local  and/or  wide-area-networked  simulation  systems 
providing  a  realistic  environment  and  involving  a  realistic  number  of  participants  add  a  new,  high  value  method  for 
training  pilots.  This  method  allows  for  tactical  training  in  a  squadron,  both  nationally  and  internationally,  which  was 
not  available  in  a  virtual  environment  until  now. 
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Young  pilots  can  train  basics  of  tactical  behavior  with  such  systems  and  save  valuable  airborne  training  time  for 
practicing  just  those  maneuvers  which  can  be  performed  in  real  flights  only  or  can  apply  in  training  with  the  real 
weapon  system  what  they  have  trained  in  the  virtual  environment  before  .  Special  combat  situations  can  be  repeatedly 
practiced  together  with  the  other  wingmen  of  a  force  package.  New  tactics  can  be  developed  and  refined. 

Aspects  of  international  joint  missions  like  an  alignment  of  communications,  tactical  behavior  and  mission  planning 
can  be  practiced  periodically,  mission  rehearsal  of  combined  air  operations  is  possible. 

A  further  developed  system  like  this  will  represent  a  good  and  flexible  basis  for  international  research  and  training 
programs  using  development  and  full  mission  or  tactical  trainer  simulations. 

4.3  Follow  on  Work 

4.3.1  Potential  German/US  Follow-on  TRACE  projects 

The  TRACE  network  has  significant  potential  to  support  future  follow-on  efforts  between  Germany  and  the  US.  The 
network  could  also  be  expanded  to  include  additional  players  using  similar  techniques.  The  TRACE  simulation 
network  using  ISDN  digital  network  at  128Kb/sec  has  been  optimized  and  introduces  an  average  of  only  100  ms.  of 
additional  simulation  latency  between  Air  Force  Research  Laboratory  located  near  Dayton,  Ohio,  and  Dasa  located 
near  Munich,  Germany.  With  this  excellent  performance,  the  TRACE  network  can  satisfactorily  support  a  variety  of 
simulation  projects  including  training  and  research  simulations.  Except  for  the  most  demanding  close-in  interactive 
simulations,  the  TRACE  network  will  support  at  least  4  entities.  Both  the  German  and  US  engineers  working  on  the 
program  are  very  pleased  with  TRACE’S  network  simulation  performance  and  would  like  to  see  the  network  used  to 
its  full  potential  in  follow-on  programs. 

On  September  16-18,  1997  a  program  review  and  demonstration  was  held  at  Wright-Patterson  AFB.  Potential 
follow-on  efforts  using  the  TRACE  network  were  discussed.  The  sections  below  describe  German  and  US  interests 
and  concerns  regarding  future  work  using  the  TRACE  network. 

4.3.2  German  Interests  and  Concerns 

The  German  emphasis  is  currently  being  placed  on  integrated  training  systems  for  highly  dynamic  aircraft  training. 
The  TRACE  network  could  be  used  to  support  this  area.  The  German  MOD  is  supporting  this  goal  through  three 
programs.  They  are 

1)  VLO  which  is  Dasa’s  ground  based  simulation  that  addresses  combined  air  operations, 

2)  TRACE,  and 

3)  WASIF  (Weapon  System  Simulation  in  Flight),  a  project  being  executed  under  EUCLID  (European  Cooperation 
under  Long  Term  in  Defense). 


The  German  portion  of  the  TRACE  project  is  part  of  a  larger  training  project  which  supports  fighter  training. 

TRACE  has  potential  for  training  air  forces.  “Air  crew  training”  and  “crew  assistance”  are  areas  which  are  being 
emphasized  in  current  German  programs.  WAS  is  a  crew  assistance  program  for  the  Euro-fighter.  ATIMS  is  a 
carrier  mission  program  which  is  aimed  at  mission  planning.  It  is  being  conducted  with  the  Navy  who  is  interested  in 
reducing  workloads.  It  directly  supports  crew  assistance  and  pilot  training. 

Several  German  programs  are  supporting  simulation  development  and  air  crew  assistance.  These  include  Dasa’s 
simulation  programs,  programs  conducted  by  the  University  of  German  Forces,  and  a  Mission  Recorder  under 
development  from  BGT  in  Germany  and  BVR  in  Israel.  TRACE  has  expanded  the  state-of-the-art  in  long  haul 
network  technology  development. 

4.3.3  US  Interests  and  Concerns 

The  US  is  interested  in  using  the  TRACE  network  to  evaluate  air  vehicle  systems  such  as  UCAVs.  There  is  a  major 
Air  Force  thrust  in  the  Unmanned  Air  Vehicle  (UAV)  area.  There  is  significant  interest  by  the  US  Air  Force  in  this 
area,  and  there  will  be  many  in-house  support  activities.  After  the  UAV  programs  have  been  better  defined,  there  will 
likely  be  several  areas  which  will  need  further  development  and  will  be  good  areas  for  cooperative  international 
research.  This  type  of  research  would  complement  US  and  German  research. 
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Another  US  interest  is  to  expand  the  TRACE  capability  by  linking  to  an  active  combat  range  and  evaluating  the 
potential  of  the  TRACE  network  to  provide  an  essential  research  capability  between  test  ranges  and  high  fidelity 
simulations  separated  by  long  distances.  Successful  demonstration  of  this  technology  would  establish  a  new 
capability  for  realistic  international  threat  mission  rehearsal  via  secure  interactive  networks. 

During  1997,  the  US’s  efforts  on  the  TRACE  program  were  reviewed  by  Dr.  Dix,  senior  representative  from 
DDR&E.  Funding  for  the  US  side  has  been  provided  primarily  with  6.2  research  funds  through  the  AFRL/FIG  Flight 
Control  Division.  The  TRACE  program  was  originally  envisioned  to  be  a  comparison  study  between  the  German 
Automated  Maneuvering  System  (AMS)  and  the  US  Integrated  Control  and  Avionics  for  Air  Superiority  (ICAAS) 
combat  pilot  aiding  systems.  The  TRACE  program  was  broken  into  two  phases  to  reduce  risk.  The  first  phase  of 
TRACE  was  network  development,  and  the  second  phase  was  to  have  been  the  comparative  evaluation.  Annex  1  of 
the  umbrella  MOU  covered  phase  1  of  the  TRACE  effort.  Dr.  Dix  perceived  the  TRACE  program  as  only  a 
networking  effort  and  as  contributing  little  to  the  US  flight  control  and  research  efforts.  His  negative  review  has 
resulted  in  difficulty  in  funding  TRACE  work.  Any  follow-on  effort  will  need  to  have  a  flight  control  emphasis  or  be 
funded  through  a  different  organization. 

4.3.4  Summary 

The  TRACE  network  performance  has  the  potential  to  support  several  types  of  future  projects.  The  most  promising 
projects  include 

1)  joint  training  via  long  haul  simulation, 

2)  UAV  research, 

3)  expand  TRACE  network  to  include  active  air  range,  and 

4)  conduct  comparative  evaluations  of  air  vehicle  systems. 


The  German  and  US  engineers  agree  that  the  TRACE  network  has  significant  future  potential  and  want  to  actively 
pursue  the  future  use  of  TRACE.  Funding  sources  for  such  a  program  need  to  be  identified. 

TRACE  is  the  only  existing  annex  to  the  umbrella  MOU  between  Germany  and  the  United  States,  and  it  is  hoped  that 
future  work  can  be  identified  to  continue  joint  work.  A  new  annex  will  need  to  be  developed  for  any  TRACE  follow- 
on  work.  Annexes  take  some  time  to  develop,  and  it  is  likely  that  formal  program  work  could  not  be  expected  until 
1999  at  the  earliest. 

A  couple  of  short  term  goals  have  been  identified  to  maintain  and  promote  the  TRACE  network  while  follow-on 
efforts  are  being  identified.  They  include  periodic  testing  of  TRACE  to  ensure  that  simulation  changes  at  either 
facility  do  not  adversely  impact  the  TRACE  network  capability.  An  occasional  demonstration  will  also  be  presented 
so  that  the  TRACE  capability  is  maintained. 


4-7 


Transatlantic  Research  into  Air  Combat  Engagements  Final  Report 

Doc.-No.:  Dasa-S-R- 1775-02  5.  TRACE  Evaluation  Production  Runs  1Dasal 


5.  TRACE  Evaluation  Production  Runs  [Dasa] 

5.1  Background 


Fig.  5-1  Testing  Schedule 


For  the  TRACE  Production  Runs  there  were  4  days  of  test  runs  and  a  final  demonstration  in  a  period  of  two  weeks 
scheduled.  Due  to  problems  in  the  AFRL  image  generator  the  scenario  S3  and  S4  were  shifted  to  Monday  and 
Tuesday  of  the  second  week.  The  originally  planned  scenario  S4  was  then  delayed  to  the  day  after. 

The  complexity  of  the  scenarios  increased  with  everyday  and  ended  with  a  joint  mission  scenario.  For  more 
complexity  in  the  joint  mission  training  sessions  the  number  of  Computer  Generated  Targets  were  raised  up  to  6.  A 
simpler  but  more  agile  scenario  was  generated  for  an  all  versus  all  training  described  below. 

An  additional  demonstration  on  both  Dasa  and  AFRL  side  with  the  test  pilots  were  shown  in  the  following  week. 
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5.2  Scenarios 

5  different  training  and  test  scenarios  were  prepared  for  the  production  runs  and  completed  by  3  new  scenarios  on 
request  of  the  involved  pilots.  Scenario  S2  to  S4  were  generated  in  the  role  of  aggressors  and  defenders  for  both  sides 
Dasa  and  AFRL. 


5.2.1  Scenario  1:  Pilot  Familiarization 

One  cockpit  of  each  side  was  active  in  this  scenario  .  The  cockpits  were  not  hostile  and  placed  on  the  same  airport  to 
fly  nearby  and  formation.  To  ensure  the  pilots  familiarization  with  the  cockpit  and  the  interconnected  system,  such  a 
scenario  were  generated  for  all  four  cockpits.  A  voice  connection  was  set  up  between  AFRL  and  Dasa  cockpits  via 
separate  telephone  line  what  enables  the  pilots  to  talk  to  and  get  to  know  each  other. 


Key  Points: 


•  2  Cockpits / 1  Airport 

•  Behavior  of  Entity 

•  Getting  familiar  with  the  System 

•  First  Contact  of  Pilots 

•  Testing  Communication 

•  Data  Recording 
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5.2.2  Scenario  2:  1  v  1  Combat 

As  in  the  scenario  before,  one  cockpit  of  each  side  was  active  but  this  time  hostile.  Between  AFRL  and  Dasa  there 
was  no  communication  system  installed  and  the  pilots  were  able  to  get  familiar  with  the  weapon  systems  of  all 
cockpits. 


Fig.  5-3  Scenario  2  Map 

Key  Points: 

•  2  hostile  Cockpits 

•  1  Airport ,  1  Airborne 

•  Getting  familiar  with  weapon  system 

•  Data  Recording 


=>  Scenario  2 A:  1  v  1  Combat  (AFRL  Blue,  Dasa  Red) 
=>  Scenario  2B:  1  v  1  Combat  (AFRL  Red,  Dasa  Blue) 
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5.2.3  Scenario  3:  2  v  2  Combat 

In  this  scenario  both  the  AFRL  and  Dasa  cockpits  were  involved.  The  forces  were  hostile  and  no  communication 
system  between  the  forces  was  installed. 


Fig.  5-4  Scenario  3  Map  \ 

1 - 


Key  Points:  X. 

•  2  hostile  Forces ,  4  Cockpits  f 

•  2  Airport,  2  Airborne 

•  Combat  Training 

•  Data  Recording 


Scenario  3A:  2  v  2  Combat  (AFRL  Blue,  Dasa  Red) 
=>  Scenario  3B:  2  v  2  Combat  (AFRL  Red,  Dasa  Blue) 
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5.2.4  Scenario  4:  4  v  2  +  2  Combat 

In  comparison  to  the  scenario  before,  the  complexity  was  increased  by  adding  at  the  AFRL  side  two  manned  combat 
stations  to  their  forces  as  well  as  adding  two  CGT’s  (Computer  Generated  Targets)  to  the  forces  on  Dasa  side.  The 
aggressors  were  split  into  two  separated  forces. 


Key  Points 

•  2  hostile  Forces ,  4  Cockpits ,  4  CGF 

•  Combat  Training 

•  Data  Recording 


Fig.  5-5  Scenario  4  Map 


=>  Scenario  4A:  4  v  2  +  2  Combat(AFRL  Blue,  Dasa  Red) 
=>  Scenario  4B:  4  v  2  +  2  Combat(AFRL  Red,  Dasa  Blue) 
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5.2.5  Scenario  5:  2  +  2  v  4  Joint  Combat 

In  this  scenario  all  4  simulators  had  a  joint  mission  against  4  CGT’s.  Two  simulators  were  controlled  by  AFRL  and 
the  other  two  and  all  four  CGT’s  by  the  Dasa  simulation.  The  hostile  forces  were  split  into  3  fighters  and  1  remotely 
located  bomber  as  aggressors.  The  joint  mission  team  had  4  fighters. 


Key  Points 

•  2  hostile  Forces ,  4  Cockpits  vs  4  CGF 

•  Combat  Training 

•  Data  Recording 


5.2.6  Added  Scenario 

On  demand  of  the  pilots,  more  complex  scenarios  were  developed  to  increase  the  effectiveness  of  the  tactical  training 
for  joint  missions  by  increasing  the  number  of  involved  entities. 

The  interconnected  system  shows  its  flexibility  and  performance  with  the  Dasa-Protocol.  For  the  usage  of  the  DIS  or 
DIS-Lite-protocoi  the  bandwidth  need  was  too  high  for  that  high  number  of  possible  entities. 


5.2.6.1  Added  Scenario:  2  +  2  v  6  Joint  Combat 

This  scenario  was  similar  to  the  S5  but  with  the  increased  number  of  6  Dasa  controlled  CGT’s.  Due  to  bandwidth 
limitations  it  was  only  performed  by  using  Dasa  protocol. 
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52.6.2  Added  Scenario:  2  +  4  v  6  Joint  Combat 

This  scenario  was  similar  to  the  S5  but  with  the  increased  number  of  6  Dasa  controlled  CGT’s  and  another  two 
manned  combat  stations  at  AFRL.  Due  to  bandwidth  limitations  it  was  only  performed  by  using  Dasa  protocol. 


Fig.  5-7  Snapshot  out  of  the  2  +  4  v  6 


The  figure  represents  a  snapshot  out  of  the  2  +  4  v  6  scenario  and  shows  about  the  highest  complexity  of  the  training 
session  which  could  be  handled  via  a  single  ISDN  telephone  line  using  Dasa  protocol,  although  the  dispersion  of  the 
entity  control  was  unbalanced  towards  the  Dasa  simulation  which  handled  2  simulators  and  6  CGT’s  and  all  their 
weapon  systems  and  missiles. 

5.2.63  Added  Scenario:  1  v  1  v  1  v  1  Combat 

This  is  a  usual  training  scenario  for  flight  training.  All  four  entities  start  the  training  at  the  same  distance  from  a 
virtual  point  on  the  map.  Every  entity  fights  against  every  other  one.  Only  SRM’s  are  allowed  and  may  only  be  used 
if  you  are  directly  behind  the  hostile  target. 

This  scenario  was  a  proof  of  the  high  resolution  ability  for  data  loss,  transferring  failure,  reliability  of  the 
interconnected  system  and  a  little  bit  of  fun  for  the  pilots. 
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6.  TRACE  Network  Connectivity [Dasa  &  AFRL1 

6.1  Network  Background 

6.2  AFRL/VACD  &  Dasa  Physical  Network  [Dasa  &  AFRL] 

6.2.1  AFRLA  ACD  Local  Network [AFRL] 

6.2.1.1  Normal  AFRL/VACD  Network 

The  AFRL/VACD  computer  deck  normally  has  two  separate  Ethernet  networks,  one  for  routine  network  traffic  and 
one  for  real-time  network  traffic.  All  of  the  Silicon  Graphics  and  Encore  91  computers  default  Ethernet  interfaces  are 
connected  to  the  “default”  network.  In  addition  each  Silicon  Graphics  used  for  real-time  has  a  second  Ethernet 
interface  that  is  connected  to  the  real-time  network.  The  Encore  RSX  computers  have  one  Ethernet  interface  which  is 
connected  to  the  real-time  network.  The  TRACE  program  utilized  the  real-time  network  to  drive  the  AFRL  simulation 
displays. 

6.2.1.2  Added  Network  Components  for  TRACE 

The  only  addition  to  the  local  network  at  AFRL  was  the  connection  of  one  of  the  Challenge’s  E-Plex  Ethernet  to  a 
hub  for  connectivity  to  the  ISDN  or  DSI  long  haul  networks.  This  connection  was  used  for  the  DIS  and  DIS-Lite 
protocols.  The  port  was  configured  differently  for  use  with  the  DSI  and  the  ISDN  as  shown  in  Table  6-1 


Network 

IP  Address 

Routing 

DSI 

ISDN 

172.17.0.20 

172.18.230 

N/A 

route  add  net  172.17.0.0  172.18.0.254 

Table  6-1 


6.2.1.2.1  Dasa  NIC  Computer 

The  Dasa  NIC  Computer  at  AFRL  is  comprised  of  a  Force  VMEbus  rack  connected  via  ScramNet  to  the  AFRL 
Simulators  and  connected  via  Ethernet  to  the  WAN  interface,  an  Ascend  Pipeline  50  ISDN  router  (2  B-channels,  total 
bandwidth  128  kbit/s). 

6.2.1.2.2  SNAP  Computer 

SNAP  grew  out  of  a  need  to  determine  the  ability  of  current  DIS  networks  to  handle  the  high  fidelity  networked 
simulations  required  by  the  Air  Force.  This  project  focused  on  the  time  delays  and  simulation  accuracies  associated 
with  networked  simulations  over  long  distances,  (or  “long-haul  simulations”)  for  highly  dynamic  vehicles. 

There  are  several  time  delay  issues  that  SNAP  addresses.  Total  end-to-end  network  delays  are  important  to  know  (to 
remain  under  the  100ms  rule  of  thumb),  but  latency  values  at  certain  subsections  within  the  overall  network  are 
equally  as  important.  Other  latency  issues  include  time  correlation  of  cues,  and  how  a  pilot  in  one  simulator 
perceives  aircraft  actions  at  a  second  simulator.  To  determine  the  time  delays  associated  with  the  network  for  these 
types  of  issues,  a  portable  timing  analysis  unit  (SNAP)  was  developed.  To  help  with  SNAP,  an  Electronic  Visual 
Display  Attitude  Sensor  (EVDAS)  was  also  developed  to  measure  when  the  pilot’s  visual  display  received  updates. 
These  two  units,  together  with  the  associated  software,  make  up  the  SNAP  system  (Figure  1 ). 

One  SNAP  computer  can  operate  alone  to  determine  several  performance  factors  of  a  single  simulator;  such  as  stick 
input  to  out-the-window  (OTW)  video  delay,  stick-to-instrument  delay,  stick-to-state  variable  update  delay,  stick-to- 
Protocol  Data  Unit  (PDU)  transmission  delay,  PDU  reception  to  state  variable  update  delay,  and  PDU  reception  to 
OTW  video  delay.  Also,  multiple  SNAP  computers  can  evaluate  the  performance  of  a  networked  simulation  by 
connecting  to  simulators  in  geographically  separate  locations  and  monitoring  the  end-to-end  delay.  SNAP  can  also 
monitor  a  network  and  give  statistics  on  network  traffic;  from  generic  Ethernet  packets  to  particular  PDU  types. 
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SNAP  is  capable  of  driving  repeatable  simulator  input  signals,  allowing  the  SNAP  operator  to  have  repeatable  test 
results.  SNAP’s  measurements  between  simulators  located  anywhere  in  the  world  is  accurate  to  within  500 
microseconds. 

To  accurately  obtain  data  from  a  simulator,  SNAP  is  capable  of  operating  synchronously  (i.e.  sample  data 
consistently  at  the  same  time  slice  within  the  frame)  with  a  simulator  in  two  different  ways.  The  first  is  to 
synchronize  SNAP’s  sampling  time  with  the  simulation  computer’s  frame  time  using  an  external  interrupt.  The 
second  method  is  for  SNAP  to  synchronize  with  the  refresh  rate  of  the  video  display  system  connected  to  EVDAS. 
SNAP  is  also  capable  of  sampling  at  a  configurable  frequency  independent  from  the  simulator,  although  this  is 
usually  undesirable  (but  occasionally  useful  when  obtaining  the  interrupt  from  the  simulator  is  too  difficult).  SNAP 
can  be  configured  to  collect  data  using  any  combination  of  sampling  methods  previously  mentioned,  but  wherever 
practical,  SNAP  should  be  used  in  synchronous  mode  to  avoid  asynchronous  sampling  problems. 

The  SNAP  computer  is  a  rack  mounted  150  MHz  Intel  Pentium  PCI/ISA  bus  system  with  an  integrated  9.4”  SVGA 
LCD  display  and  a  270  Mbyte  SyQuest  removable  cartridge  drive.  The  SyQuest  cartridge  can  be  removed  and 
secured  if  it  contains  sensitive  information. 

The  computer’s  expansion  slots  house  several  off-the-shelf  PC  cards  and  an  in-house  developed  EVDAS  card.  The 
off-the-shelf  PC  cards  include  a  multi-function  input/output  board,  two  Ethernet  boards,  a  global  positioning  system 
(GPS)  board,  a  SCRAMNet  shared  memory  board  and  a  SVGA  video  card. 

SNAP,  through  National  Instruments’  multi-function  I/O  card,  has  two  analog  signal  outputs,  eight  differential  analog 
signal  inputs,  and  four  digital  I/O  channels  (16-bit,  4-bit,  2-bit,  and  1-bit).  The  multi-function  board  provides  several 
counters/timers  for  frequency  and  event  counting.  The  board  also  has  an  external  sync  input  capability.  This  board  is 
used  to  drive  stick  signals  and/or  record  simulator  state  variables. 

3Com  Ethernet  boards  are  used  to  passively  extract  PDU  information  from  any  network  running  DIS.  Using  two 
Ethernet  boards  enables  a  single  SNAP  computer  to  monitor  PDU  traffic  at  two  different  points  within  a  single 
simulation  site. 

The  GPS  receiver,  which  is  accurate  to  within  2  microseconds,  is  used  to  correlate  remotely  gathered  data  when 
multiple  SNAP  machines  are  used  on  long-haul  simulations.  SNAP’s  GPS  receiver  is  composed  of  a  PC  plug-in 
card,  an  antenna/receiver,  and  a  GPS  synchronized  timing  module. 

The  SCRAMNet  card  is  used  to  read  state  variable  information  from  a  simulation  network  using  this  type  of 
architecture. 

The  SNAP  computer  operates  with  Intel’s  RMX  (iRMX)  real-time  operating  system  with  MS-DOS  running  as  a  task. 
The  iRMX  operating  system  allows  for  real  time  interrupt-handling  and  precise  timing  of  collected  data.  An  MS- 
DOS  sub-task  is  used  to  run  the  Graphical  User  Interface  (GUI).  The  GUI  allows  the  user  to  control  SNAP’s 
hardware  and  software.  The  GUI  was  developed  using  National  Instrument’s  LabWindows.  Additionally,  custom 
analysis  software  was  developed  to  quickly  process  the  data  files  and  assist  in  producing  a  report. 


The  second  major  hardware  component  of  the  SNAP  system,  EVDAS,  was  designed,  developed,  and  constructed  in- 
house.  EVDAS  consists  of  an  interface  card  (located  in  the  SNAP  computer)  and  a  measurement  unit  (EVDAS  box). 
The  EVDAS  interface  card  provides  the  necessary  digital  information  based  on  video  signals  passed  between  the 
EVDAS  box  and  the  SNAP  computer.  The  EVDAS  interface  card  also  contains  a  highly-stable  microsecond  crystal 
clock  used  for  accurate  time  stamping  (by  the  SNAP  computer).  The  EVDAS  box  detects  motion  in  visual  images, 
such  as  wing  tips  or  the  horizon  and  sends  this  information  to  the  EVDAS  interface  card. 

The  SNAP  computer  and  EVDAS  box  were  integrated  into  the  AFRL  facility  to  allow  for  the  measurement  of 
various  simulation  latencies. 
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Fig.  6-1  SNAP  Description 


6.2.2  Dasa  Local  Network [Dasa] 

For  the  TRACE  program,  an  ISDN  line  was  connected  to  the  ISDN  Router  allowing  secure  access  from  the  WAN. 
The  ISDN  router  routes  the  WAN  into  a  general  local  network  where  the  ASTi  Voice  communication  system,  the 
SNAP  equipment  and  the  NIC  computer  are  connected.  For  the  production  runs  the  ASTi  communication  system  was 
replaced  by  a  simple  telephone  link  between  the  local  communication  systems  on  both  sides.  In  addition  to  its  normal 
functions,  the  NIC  computer  acts  as  a  gateway  between  the  WAN  and  LAN  and  connects  to  LAN  2  over  the  firewall. 

The  LAN  2  network  connects  the  VLO  simulation  components  (VLO  simulator,  CGF’s,  Data  Recorder)  with  the 
development  system  and  the  Network  Interface  Computer  (NIC). 

The  NIC  in  this  diagram  represents  the  Dasa-NIC  and  the  DIS-  and  DIS-Lite  NIC  that  was  developed  for  the  TRACE 
program. 

No  gateway  exists  between  the  Dome  Simulation  and  the  VLO-Simulation  networks. 

Data  is  exchanged  between  the  simulations  via  SCRAMNet  shared  memory.  Data  exchange  between  the  SCRAMNet 
interface  and  the  VLO  components  and  between  the  components  themselves  is  performed  via  local  shared  memory. 

The  SNAP  equipment  was  connected  to  the  system  via  a  SCRAMNet  interface  for  real-time  data  sampling  and  by 
Ethernet  for  PDU  collection. 

The  Dasa  Scenario  Manager  was  modified  and  special  configured  via  a  second  NIC  for  the  TRACE  program.  This 
common  initialization  not  only  runs  using  the  Dasa  protocol  but  also  the  DIS  and  DIS-Lite  protocols.  Additionally,  it 
enables  the  operator  to  record  and  replay  the  training  sessions  for  all  used  protocols,  although  it  is  designed  primarily 

for  the  Dasa  protocol. 
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Fig.  6-2  Dasa  local  network  configuration 

6.2.2.1  Dasa  NIC  Computer 

The  Dasa  NIC  (Network  Interface  Computer)  is  a  portable  software  module  which  runs  on  several  platforms  and  is 
used  to  ensure  overall  compatibility  across  the  entire  VLO  simulation  network.  For  the  TRACE  program,  this 
module  was  implemented  within  the  Scenario  Manager  and  on  standalone  computers.  Two  NIC’s  were  used  in  the 
local  Dasa  simulation  network  and  one  NIC  was  used  at  AFRL. 

The  Scenario  Manager  ran  on  a  Silicon  Graphics  platform  with  all  the  NIC’s  running  standalone  on  FORCE  VME- 
platforms  with  Sparc  CPU’s. 

At  Dasa,  one  NIC  was  used  to  connect  the  local  simulation  via  ISDN  to  the  AFRL  simulation’s  single  Dasa-NIC. 

The  second  NIC  was  used  to  connect  the  Scenario  Manager  with  its  standardized  Dasa-Protocol  to  the  TRACE 
simulation  net. 

If  the  DIS-  or  DIS-Lite  protocol  was  used  for  WAN-connection,  the  Dasa-NIC  connected  to  the  ISDN  router  was 
replaced  by  the  DIS  /  DIS-Lite  NIC  (same  hardware  different  software). 

6.2.2.2  Added  Network  Components  for  TRACE 
6.2.2.2.1  SNAP  Computer 

The  SNAP  equipment  provided  by  AFRL  was  connected  to  the  Ethernet  network  between  the  WAN  router  and  the 
NIC,  to  the  SCRAMNet  interface,  to  the  video  display  system,  to  the  control  stick  and  to  an  interrupt  signal  provided 
by  the  Dasa  simulators.  The  Ethernet  connection  allowed  SNAP  to  collect  and  timestamp  transmitted  or  received 
PDUs  for  later  analysis.  Before  connection  SNAP’s  SW  was  modified  to  allow  it  to  collect  all  three  protocol’s 
PDUs.  This  modification  amounted  to  the  addition  of  code  to  collect  Dasa  PDUs.  The  SCRAMNet  connection 
allowed  SNAP  to  collect  and  timestamp  data  placed  into  SCRAMNet  shared  memory.  Since  SCRAMNet  was  used  to 
exchange  local  data  between  the  VLO-  and  the  Dome-Simulators  and  represents  the  shared  memory  HW  of  the  VLO 
simulation,  this  data  was  the  simulator’s  (simulated  aircraft  and  missiles)  state  data  (roll,  roll  rate,  pitch,  etc.).  The 
connection  to  the  video  display  system  allowed  SNAP  to  capture  and  timestamp  changes  in  the  pilot’s  video  display. 
This  is  used  to  indicate  when  the  result  of  a  control  stick  input  is  depicted  on  the  pilot’s  visual  display.  The 
connection  to  the  control  stick  allowed  SNAP  to  either  record  (sample)  stick  inputs  or  to  drive  stick  inputs.  Sampled 
stick  inputs  or  SNAP  induced  stick  inputs  are  recorded  and  timestamped  allowing  for  measurements  of  delays 
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through  the  simulator.  The  last  connection,  the  interrupt  signal  from  the  Dasa  simulator,  is  used  to  synchronize 
SNAP’s  data  sampling  to  the  simulator.  Using  these  connections,  SNAP’s  data  can  be  used  to  calculate  the  delay 
between  a  stick  input  to  a  resultant  state  change,  to  a  visual  display  change  and  to  PDU  transmission.  Additionally, 
SNAP’s  data  can  be  used  to  calculate  the  delay  between  the  reception  of  a  PDU  from  a  remote  site  to  the  resultant 
change  in  the  remote  entity’s  local  state  variables  and  remote  entity’s  local  visual  attitude  change. 


Fig.  6-3  Dasa-SNAP-Configuration 


62.2.2.2  DIS-,  DIS-Lite-NIC 

For  the  TRACE  program,  a  DIS-  and  a  DIS-Lite  NIC-SW-module  were  developed  based  on  Mak  Technologies 
object  library  ensuring  compliance  with  the  DIS  standard  protocol.  These  modules,  physically  installed  on  the  Dasa 
NIC-HW,  replaced  the  Dasa-NIC  SW  module  during  the  TRACE  tests. 
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6.2.3  AFRL/VACD  &  Dasa  Long  Haul  Network [AFRL] 


Fig.  6-4  TRACE  Network  Map 
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6.2.3.1  Defense  Simulation  Internet 

In  addition  to  a  standard  ISDN  telephone  line,  a  simulation  connection  using  the  DSI  (Defense  Simulation  Internet) 
was  tested.  DSI  equipment  was  installed  at  Daimler  Benz  Aerospace  AG  for  several  months.  Since  Dasa  had  no 
direct  connection  to  the  DSI,  an  ISDN  tail  circuit  (entry  point)  was  established  to  connect  them  to  the  DSI  hub  near 
Stuttgart.  This  limited  the  DSI  bandwidth  to  a  theoretical  128  kbit/sec.  Prior  to  the  production  runs  DARPA/JPO 
removed  the  DSI  not  only  from  Dasa  but  also  from  Germany  preventing  it  from  being  a  candidate  for  use  during  the 
production  runs.  However,  prior  to  its  removal,  based  on  the  DSI’s  achieved  transfer  rates,  delay  times,  handling 
and  availability,  the  DSI  was  determined  not  to  be  the  best  choice  for  use  in  the  production  runs. 

All  the  measurement  data  reported  herein  refer  to  the  actual  data  rates  and  do  not  consider  any  overhead  by  any  non¬ 
application  protocol  (IP,  UDP,  Streams) 

•  Throughput 

In  the  week  starting  with  1  April  1997  we  achieved  a  bandwidth  of  74  kbits/s.  In  previous  connections,  we  barely 
reached  60  kbits/s  at  a  very  maximum.  The  results  were  obtained  using  several  different  packet  sizes  and  buffer 
sizes  (buffer  size  is  established  to  allow  some  kind  of  burst  mode)  to  look  for  the  best  values. 


•  Delay-Times 

At  an  estimated  average,  we  do  get  300ms  round-trip  time,  which  is  150ms  one  way  and  50%  above  the  maximum 
specification  time  (as  given  in  the  DIS  standard).  Typical  rates  were  270ms  up  to  380ms.  These  values  were 
obtained  with  either  a  test  program  which  works  in  very  much  the  same  way  that  our  application  works  [using 
UDP  rather  than  TCP])  or  with  a  standard  ping  command.  There  is  no  real  difference  observed  between  these  two 
methods. 

•  Availability 

The  estimated  availability  was  about  50%  of  the  scheduled  time.  The  DSI  was  scheduled  up  to  a  week  in  advance 
but  could  be  scheduled  up  to  one  day  in  advance  of  any  tests.  On  the  day  of  testing,  Dasa  would  create  the  ISDN 
connection  to  the  DSI  using  a  CSU/DSU  supplied  by  the  DSI  administrators.  Many  times  this  connection  would 
fail  and  the  network  support  center  would  be  called  to  determine  the  cause  and  means  to  correct  the  problem.  If 
the  ISDN  connection  was  successful,  many  times  we  found  that  the  routers  at  Vaihingen  or  Ramstein  would  be 
experiencing  problems,  thus  yielding  no  network.  This  would  often  take  several  hours  to  correct  (if  corrected  at 
all)  and  often  resulted  in  the  rescheduling  of  the  test  or  changing  to  the  ISDN  network  to  perform  scheduled  tests. 
Often  after  a  successful  network  connection,  the  streams  would  fail,  the  ISDN  connection  would  drop  out,  or  the 
routers  would  experience  problems  thus  dropping  the  network  connection. 


6.2.3.2  Integrated  Services  Digital  Network 
6.2.3.2.1  ISDN  Router 

The  first  attempt  to  connect  via  an  ISDN  line  used  a  PC  based  ISDN  router.  This  router  consisted  of  a  Pentium 
computer  configured  with  a  ISDN  router  card  manufactured  by  ITK  Germany.  This  setup  required  additional  ITK- 
router-SW  running  on  Novell-OS  for  configuring  the  card.  The  system  was  difficult  to  install  because  it  used 
software  running  under  Novell-OS  but  installed  and  started  from  a  DOS  platform.  Additionally,  many  of  the 
promised  features  and  functions  could  not  be  setup.  It  was  impossible  to  bundle  the  two  ISDN  B-channels  to  achieve 
the  required  128  kbit/sec  bandwidth.  This  was  a  result  of  the  difference  in  the  European  and  American  ISDN 
standards  and  switches.  Because  of  this,  the  PC  based  ISDN  router  could  not  be  used  for  the  TRACE  project  even 
though  it  had  been  successfully  used  by  Dasa  in  many  European  projects. 

Instead,  the  “Ascend  Pipeline  50“  router  was  selected  and  implemented.  It  was  easy  to  install,  more  efficient  and  a 
reliable  alternative. 

6.23.2.2  ASCEND  Pipeline  50  Router 

The  original  agreement  was  to  use  the  Defense  Simulation  Internet  and  a  commercial  ISDN  line  for  TRACE  network 
connections.  The  two  networks  were  to  be  compared  and  the  better  of  the  two  chosen  for  use  during  the  production 
runs.  Since  AFRL  had  no  experience  with  ISDN,  it  relied  on  its  local  telecommunication  company  to  suggest  both 
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the  type  of  ISDN  and  type  of  ISDN  terminal  adapter.  The  resulting  ISDN  Basic  Rate  Interface  with  2  64  kbps  B- 
channels  and  1  16  kbps  D-channel  were  suggested  and  connected.  Ameritech,  the  local  telecommunication  company, 
also  suggested  the  ASCEND  Pipeline  50  ISDN  router.  This  router  was  purchased  but  not  connected  immediately, 
opting  for  the  Dasa  provided  ITK  ISDN  router  described  above.  After  discovering  that  the  ITK  router  would  not 
fulfill  the  network  needs,  Dasa  purchased  an  ASCEND  router  and  implemented  it  on  their  side.  After  some  minor 
modifications  to  the  router  setup  the  two  ASCEND  routers  connected  to  one  another  with  both  B-channels  providing 
the  required  128  kbps  bandwidth.  Some  limitations  were  not  overcome  however.  AFRL  and  Dasa  were  unable  to 
provide  password  security  for  their  router  connections  (time  limitations  prevented  the  full  familiarization  with  the 
routers).  This  did  not  present  a  problem  since  the  routers  were  disconnected  from  the  ISDN  phone  line  at  the  end  of 
each  day  (this  was  not  only  to  prevent  unauthorized  access  but  also  to  prevent  the  ASCEND  routers  from  connecting 
to  the  distant  network  unknowingly). 

6.233  Asynchronous  Transfer  Mode 

At  the  kickoff  meeting  the  use  of  an  Asynchronous  Transfer  Mode  (ATM)  network  was  discussed.  These  fairly  new 
network  offering  “bandwidth  on  demand”  with  bandwidths  up  to  OC12  (600  Mbits/sec).  In  researching  the 
availability  of  ATM  networks  it  was  discovered  that  the  monthly  cost  was  very  high  and  above  the  capability  of 
AFRL  to  implement.  Therefore,  the  decision  to  not  include  ATM  as  a  network  option  was  made. 

6.3  AFRL/VACD  &  Dasa  Network  Communication  |Dasa  &  AFRL] 


PDUs  come  in  many  different  types;  each  type  is  designed  to  communicate  a  specific  piece  of  simulation  information 
to  other  simulation  sites.  The  most  common  PDU  type,  the  Entity  State  PDU,  is  designed  to  convey  the  locally 
simulated  “entity’s”  (combatant)  “state”  (location,  velocity,  acceleration,  roll,  pitch,  yaw,  etc.)  information  to  other 
(interested)  simulators.  Other  PDU  types  announce  a  weapon  firing,  a  weapon  detonation,  entity  collision(s),  radio 
transmissions,  radar  and  other  electromagnetic  emissions,  simulation  control  (start,  stop,  freeze,  and  resume),  and 
logistics.  Whenever  a  simulation  has  such  information  to  send  to  other  simulation  sites,  it  processes  the  information, 
formats  it  into  the  PDU  format,  and  sends  the  PDU  out  over  the  network  to  the  other  simulation  sites. 

PDUs  are  typically  broadcast  over  the  network.  That  is,  the  information  is  not  destined  for  a  single  simulation  site, 
but  rather  it  is  sent  to  every  simulation  site  on  the  network.  It  is  up  to  the  local  site  to  filter  out,  or  ignore,  the  PDUs  it 
is  not  interested  in.  For  example,  an  Army  tank  simulation  might  filter  out  Navy  ship  simulation  PDUs,  as  the  tank 
simulation  does  not  require  ship  simulation  information  to  function  properly  (unless  the  Army  tank  is  near  the  Navy 
ship). 
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Filtering  network  traffic  is  a  critical  process.  Physically,  computer  systems  have  limited  memory  and  processing 
capability.  While  memory  space  continues  to  increase  and  processing  capabilities  grow,  a  large  network  simulation 
(like  Warbreaker  or  the  Synthetic  Theater  of  War  exercises),  containing  thousands  of  entities  generating  many 
thousands  of  PDUs  during  the  course  of  the  simulation,  could  easily  overwhelm  a  simulation  computer  with 
information.  Filtering  reduces  the  simulation  computer  processing  workload  so  it  may  concentrate  on  performing  its 
own  simulation  rather  than  processing  the  network  traffic.  Often,  a  separate  computer  is  used  to  access  the  main 
network  -  even  in  this  case,  it  is  wise  to  filter  out  unimportant  entities. 

Similarly,  a  process  known  as  “dead  reckoning”  is  a  crucial  part  of  the  DIS  protocol  suite.  Without  dead  reckoning, 
each  entity  is  required  to  continuously  transmit  its  state  information  to  the  other  simulation  sites,  resulting  in  flooded 
networks  choked  with  information.  DIS  uses  dead  reckoning  to  reduce  the  information  transferred  between  sites. 
Each  individual  site  maintains  a  “copy”  of  both  its  own  and  the  remote  simulation  entities.  Based  on  past  knowledge, 
the  local  simulation  site  predicts  (extrapolates)  the  current  and  future  states  of  the  entities  (dead  reckons),  and  unless 
new  information  is  given,  the  local  simulation  assumes  the  entities  are  where  their  dead  reckoned  positions  places 
them.  The  dead  reckoning  algorithm  utilizes  a  user  set  threshold  for  angular  and  positional  errors.  If  the  dead 
reckoning  threshold  is  not  exceeded,  the  aircraft  state  is  typically  updated  at  a  5  second  time  interval  (often  called  a 
“heartbeat”).  This  process,  while  greatly  reducing  the  amount  of  network  traffic,  causes  severe  problems  with 
endgame  situations.  Often,  weapons  run  on  the  local  simulation  computer  will  claim  a  hit  based  on  the  dead- 
reckoned  network  entity.  However,  the  target  aircraft  might  have  escaped  the  weapon’s  attack  by  performing  some 
maneuver  that  the  dead-reckoning  wouldn’t  account  for,  leading  to  a  “I-hit-you-no-you-didn’t”  issue  with  negative 
training  implications. 
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6.3.1.1  Special  Modifications  for  TRACE 

6.3.1.1.1  Modifications  for  TRACE  IR  Data 

In  order  to  satisfy  the  needs  of  the  Dasa  medium  range  missile  and  the  IR  missile  several  modifications  were 
made  to  AFRL’s  standard  DIS  interface. 

6.3.1.2  Medium  Range  Missile  Seeker  Head  Information 

An  Electromagnetic  Emission  PDU  with  a  frequency  of  33  Hz  was  sent  when  the  status  of  the  medium  range 
missiles  seeker  head  changed  from  guided  to  autonomous. 

6.3.1.3  Fuel  Flow  and  Throttle  Position 

An  Electromagnetic  Emission  PDU  with  a  frequency  of  22  Hz  containing  the  throttle  position  and  fuel  flow  was 
sent  when  the  throttle  position  changed  or  the  fuel  flow’s  most  significant  6  bits  changed. 

6.3.1.4  Dasa  Missile  Number 

The  Dasa  NICs  required  knowledge  of  the  missile  number  from  the  AFRL  missiles.  This  number  was  encoded 
in  the  Extra  field  of  the  Entity  Type  sent  in  the  Fire  PDU. 

6.3.1.5  Dasa  Missile  Status  and  Break  Condition 

The  missiles  endgame  status  and  break  condition  was  encoded  into  the  Detonation  PDUs  result  field  instead  of 
using  the  standard  result  codes. 

6.3.1.6  Radar  PDUs 

Electromagnetic  Emission  PDUs  were  sent  out  once  per  second  for  active  radars.  Each  radar  would  send  one 
PDU  for  each  aircraft  that  it  painted.  Table  6-2  outlines  how  the  Electromagnetic  Emissions  PDU  fields  are 
filled.  The  radar  frequency  and  beam  strength  were  the  average  over  the  previous  second  of  operation. 
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Field  Size 


(bits) 

Electromagnetic  Emissions  PDU  Fields  f 

Data 

Protocol  Version — 8-bit  enumeration 

VR-Link  fills 

Exercise  ID — 8-bit  unsigned  integer 

VR-Link  fills 

PDU  Tvpc — 8-bit  enumeration 

VR-Link  fills 

96 

PDU  Header 

Protocol  Family — 

VR-Link  fills 

Time  Stamp — 32-bit  unsigned  integer 

VR-Link  tills 

Length — 16-bit  unsigned  integer 

VR-Link  tills 

Padding — 16  bits  unused 

VR-Link  fills 

Emitting 

Site — 16-bit  unsiencd  integer 

AFRL  site  id 

48 

Entity 

Application — 16-bit  unsigned  integer 

AFRL  missile  application  id 

ID 

Entity — 16-bit  unsigned  integer 

AFRL  missile  id 

Site — !  6-bit  unsigned  integer 

VR-Link  fills 

48 

Event  ID 

Application — 16-bit  unsigned  integer 

VR-Link  tills 

Event — 16-bit  unsigned  integer 

VR-Link  fills 

8 

Request  ID 

8-bit  enumeration 

VR-Link  tills 

8 

Number  of  Systems  (N) 

8-bit  unsigned  integer 

1 

32 

Padding 

32  bits  unused 

0 

System  Data  Length 

8-bit  unsigned  integer 

VR-Link  fills 

Number  of  Beams  { M) 

8-bit  unsigned  integer 

1 

Padding 

16  bits  unused 

Emitter  Name — 16-bit  enumeration 

Radar  type 

Emitter  System 

Function — 8-bit  enumeration 

Radar  mode 

Emitter  ID  Number — 8-bit  unsigned  integer 

Location  in 

x-Component — 32-bit  floating  point 

0.0  ; 

Entity 

v-Component — 32-bit  floating  point 

0.0 

Coordinates 

z-Component— 32-bit  floating  point 

0.0 

Beam  Data  Length 

8-bit  unsigned  integer 

VR-Link  tills 

Beam  ID  Number 


8-bil  unsiencd  integer 


Beam  Parameter  Index 

16-bit  unsigned  integer 

Fundamental 

Parameter 

Data 

Frequency — 32-bit  floating  point 

Radar  frequency  r 

Frequency  Range — 32-bit  floating  point 

0.0 

ERP— 32-bit  floating  point 

Beam  strength 

PRF — 32-bit  floating  point 

0.0 

Pulse  Width — -32-bit  floating  point 

0.0 

Beam  Azimuth  Center — 32-bit  floating  point 

Beam  azimuth 

0.0 

Beam  Elevation  Center — 32-bit  floating  point 

Beam  elevation 

Beam  Elevation  Sweep — 32-bit  floating  point 

0.0 

Beam  Sweep  SYNC — 32-bit  floating  point 

0.0 

Beam  Function 

8-bit  enumeration 

0 

Number  of  Targets  in  the  Track/Jam 
Field 

8-bit  unsigned  integer 

1 

High  Density  Track/Jam 

8-bil  enumeration 

0 

Padding 

8  bits  unused 

0 

Jamming  Mode  Sequence 

32-bit  unsiened  integer 

0 

Track/Jam 

Site — 16-bit  unsigned  integer 

Id  of  Dasa  aircraft  painted 

Application — 16-bit  unsigned  integer 

Id  of  Dasa  aircraft  painted 

Entity — 16-bit  unsigned  integer 

Id  of  Dasa  aircraft  painted 

Emitter  ID — 8-bit  unsigned  integer 

0 

Beam  ID— -8-bil  unsigned  integer 

0 

Table  6-2  Emission  PDU 
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6.3.2  DIS-Lite  Protocol fAFRL1 
6.3.2. 1  Background 

The  DIS-Lite  protocol  was  developed  by  Mak  Technologies  under  a  Small  Business  Innovative  Research 
(SBIR)  contract.  The  protocol  breaks  the  Entity  State  PDU  into  two  new  PDUs,  the  Query  Response  PDU  and 
the  Kinematics  PDU.  The  Query  Response  PDU  will  be  issued  upon  creation  of  an  entity  or  in  response  to  a 
query  from  a  remove  simulation  site.  This  PDU  contains  the  static  information  in  the  Entity  State  PDU.  The 
Kinematics  PDU  contains  the  dynamic  entity  state  information.  See  [Taylor,  Darrin  Sc.  D.  “DIS-Lite  &  Query 
Protocol”,  13th  DIS  Workshop  Proceedings.  Paper  No.:  95-13-113.]  and  [Taylor,  Darrin,  Sc.  D.  “DIS-Lite  & 
Query  Protocol:  Message  Structures”,  14th  DIS  Workshop  Proceedings.  Paper  No.:  96-14-093.] 

Protocol  Details  The  DIS-Lite  protocol  defines  4  new  PDUs:  the  Query  Response  PDU  (QR-PDU),  the 
Kinematic  PDU  (KIN-PDU),  the  Lite  Query  PDU  (LTQ-PDU),  and  the  Simulation  Done  PDU  (SD-PDU).  The 
data  contained  in  the  PDUs  are  delineated  below.  The  next  section  Darrins  paper:  Taylor,  D.  Sc.  D.,  “DIS-Lite 
&  Query  Protocol:  Message  Structures”,  14th  DIS  Workshop,  Paper  No.:  96-14-093. 
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6.3.2.1.1  Query  Responce  PDU 

The  QR-PDU  is  the  static  data  from  the  DIS  Entity  State  PDU  (ES-PDU)  and  are  only  sent  when  the  entity 
enters  the  exercise,  when  any  of  the  static  data  changes,  when  an  entity  receives  an  LTQ-PDU,  or  when 
recovering  from  simulator  problems.  The  sequence  number  is  incremented  whenever  any  of  the  static  data 
changes.  This  number  is  also  contained  in  the  KIN-PDU  which  helps  maintain  consistency  of  the  data.  If  a 
KIN-PDU  is  received  that  has  a  sequence  number  that  the  receiver  has  not  received,  the  sender  will  be  queried 
for  a  QR-PDU.  The  Time  Out  parameter  tells  the  receivers  when  the  sender  will  send  data  again  and  is  used 
instead  of  the  usual  DIS  heartbeat.  Slow  moving  or  stationary  entities  may  wait  for  long  periods  before  sending 
out  any  data.  The  Group  Number  represents  a  set  of  entities  that  are  competing  for  bandwidth  and  the  Group 
Size  is  the  number  of  entities  in  the  group.  Articulated  parts  are  handled  the  same  as  in  an  ES-PDU. 


Query  Response  PDU 

Section 

Size  in  bits 

DIS  PDU  Header 

96 

Queried  Entity  Identifier 

48 

Sequence 

8 

Dead  Reckon  Algorithm 

8 

Capabilities 

32 

Appearance 

32 

64 

Guise 

64 

Time  Out 

32 

Location 

192 

Orientation 

96 

Velocity 

96 

Angular  Velocity 

96 

Acceleration 

96 

Marking 

96 

Force  Id 

8 

Art  Part  Header 

8  =  z 

Group  Number 

8 

Group  Size 

8 

Art  Part  Record 

z  *  128  bits 
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6.3.2.1.2  Kinematic  PDU 

The  KIN-PDU  contains  the  dynamic  data  for  the  entity  and  are  sent  when  the  dead  reckon  thresholds  are 
exceeded  or  when  any  articulated  part  data  changes.  The  size  of  this  PDU  is  dependent  upon  the  dead  reckoning 
algorithm  currently  in  effect.  A  Maximal  KIN-PDU  contains  all  the  optional  fields  and  a  Minimal  KIN-PDU 
contains  none  of  the  optional  fields.  When  an  entity  reaches  a  threshold  time  out  as  it  will  send  a  finite  number 
of  Maximal  KIN-PDUs  before  smaller  KIN-PDUs  are  sent.  The  data  contained  in  a  KIN-PDU  is  specified  by 
the  Kinematic  PDU  Enumeration  field  which  is  dependent  upon  the  dead  reckoning  algorithm  in  effect  and 
which  threshold  was  crossed.  The  QR-Sequency  corrseponds  to  the  sequence  number  in  the  last  QR-PDU  sent. 
The  K-Sequence  number  is  associated  with  the  KIN-PDU  and  is  used  in  conjunction  with  the  QR-PDU  Time 
Out  value. 


Kinematic  PDU 

Section 

Size  in  bits 

DIS  PDU  Header 

96 

Entity  Identifier 

48 

K-Sequence 

8 

QR-Sequence 

8 

Art  Part  Header  Word  Count  -  optional 

8  =  x 

Kinematic  PDU  Enumeration  -  optional 

8 

Unused  -  optional 

16 

Location  -  optional 

192 

Orientation  -  optional 

96 

Velocity  -  optional 

96 

Acceleration  -  optional 

96 

Angular  Velocity  -  optional 

96 

Time  Out  -  optional 

32 

Art  Data  Header 

mi 

Art  Data  Array  -  optional 

y  *  32  1 

6.3.2.1.3  Lite  Query  PDU 

The  LTQ-PDU  is  sent  when  information  about  an  entity  is  needed.  The  receiving  entity  will  respond  by  sending 
a  QR-PDU  and  a  finite  number  of  Maximal  KIN-PDUs.  The  Queried  Entity  Identifier  represents  who  is  being 
queried.  The  Sequence  Number  if  positive  refers  to  a  request  for  a  QR-PDU  with  that  sequence  number  and  if 
negative  refers  to  a  KIN-PDU  with  the  corresponding  positive  sequence  number. 


Lite  Query  PDU 

Section 

Size  in  bits 

DIS  PDU  Header 

96 

Queried  Entity  Identifier 

48 

Sequence  Number 

8 
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6.3*2.1.4  Simulation  Done  PDU 

The  SD-PDU  is  sent  to  inform  all  the  simulations  in  the  exercise  that  an  entity  has  left  the  exercise. 


Simulation  Done  PDU 

Section 

Size  in  bits 

DIS  PDU  Header 

96 

Entity  Identifier 

48 

Differences  from  DIS  Standard  ES-PDUs  are  no  longer  the  mechanism  to  broadcast  time  critical  data.  This 
function  has  been  moved  to  the  KIN-PDU.  The  QR-PDU  and  the  KIN-PDU  work  together  to  keep  receivers 
informed  of  the  state  of  remote  entities.  Reliability  is  maintained  through  the  use  of  sequence  numbers  and 
individual  entities  time  out  values  instead  of  the  traditional  DIS  heartbeat.  Minimal  KIN-PDUs  are  sent  at  entity 
time  outs  as  a  heartbeat  instead  of  a  full  ES-PDU  to  lower  bandwidth  usage. 

63.2.1.5  Query  Response  PDU 

The  QR-PDU  contains  most  of  the  data  in  an  ES-PDU  but  is  not  used  for  time  critical  data  like  the  Entity  State 
PDU.  The  sequence  number,  time  out,  group  number,  and  group  size  are  not  present  in  an  ES-PDU.  Also,  this 
PDU  can  be  different  sizes  depending  upon  the  dead  reckoning  algorithm  that  is  in  effect,  but  it  is  still  smaller 
that  an  ES-PDU. 

63.2.1.6  Kinematic  PDU 

The  KIN-PDU  contains  an  augmented  subset  of  the  data  contained  in  an  ES-PDU.  Articulated  parts  are  handled 
differently  and  more  efficiently  than  in  an  ES-PDU. 

63.2.1.7  Lite  Query  PDU 

DIS  does  not  have  an  equivalent  PDU. 

63.2.1.8  Simulation  Done  PDU 

In  a  normal  DIS  exercise,  simulations  are  notified  of  entities  leaving  by  the  final  bit  being  set  in  an  ES-PDU’s 
appearance  bits  or  by  the  entity  timing  out. 


633  Dasa  Protocol [Dasal 

633.1  Background 

The  Dasa  Protocol  was  developed  in  a  national  technology  study  project  called  “Verbundene  Luftkriegs 
Operation  (VLO)“.  The  VLO  project  started  in  1992.  The  goal  was  to  develop  an  optimized  protocol  for  use  in 
air  combat  simulation  applications. 

633.2  Protocol  Details 

The  Dasa  Protocol  comprises  9  Protocol  Data  Units  (PDU’s).  For  simulation  management,  the  available  PDU’s 
are: 

♦  Command  PDU 

♦  Data  Exchange  PDU 

and  for  data  transfer  during  simulation  operation  the  available  PDU’s  are: 
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♦  Entity  Appearance  PDU 

♦  Complex  Dead  Reckoning  PDU 

♦  Simple  Dead  Reckoning  PDU 

♦  Radar  PDU 

♦  Jammer  PDU 

♦  Flare  PDU 

♦  Chaff  PDU 

The  PDU’s  are  delineated  in  the  following  chapters. 

6.3.3.2.1  Command  PDU 

The  Command  PDU  is  used  for  sending  simulation  management  commands  to  the  participants  of  an  simulation 
exercise. 

The  command  field  contains  commands  like  Start,  Stop,  Initialize. 

The  effect  time  denotes  the  time  when  the  command  is  valid. 


COMMAND  PDU 

Sender  ID 

site 

uint8 

application 

uint8 

pdu  type  =  1 

uint8 

Sender  ID 

entity 

uint8 

Receiver  ID 

site 

uint8 

application 

uint8 

entity 

uint8 

command  ID 

uint8 

effect  time 

uint32 

total  96  bits  (12  bytes) 

Fig.  6-6  Command  PDU 


6.3.3.2.2  Data  Exchange  PDU 

The  Data  Exchange  PDU  is  mainly  used  for  data  transfer  from  or  to  the  Simulation  Manager.  The  contents  field 
describes  the  contents  of  the  data  fields. 
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DATA  EXCHANGE  PDU 

Sender  ID 

site 

uint8 

application 

uint8 

pdu  type  =  2 

uint8 

Sender  ID 

entity 

uint8 

Receiver  ID 

site 

uint8 

application 

uint8 

entity 

uint8 

contents 

uint8 

the  data 

52  bytes 

total  480  bits  (60  bytes) 

Fig.  6-7  Data  Exchange  PDU 


6.3.3.2.3  Entity  Appearance  PDU 

This  PDU  contains  the  status,  the  appearance  and  other  data  of  an  entity  which  are  changing  slowly  or  aren’t 
changing  at  all  during  the  lifecycle  of  an  entity. 

The  entity  type  specifies  the  superior  type  like  aircraft,  missile,  etc.  The  subtype  provides  more  precise 
information  about  the  given  entity  type.  The  status  field  communicates  the  status  of  an  entity  such  as  active, 
missile  in  flight,  or  missile  hit,  etc.  The  force  number  tells  the  side  (blue,  red,  neutral)  the  entity  belongs  to. 

The  appearance  field  contains  data  like  gear  state,  afterburner  state,  IFF,  infrared  information  etc. 


ENTITY  APPEARANCE  PDU 

Entity  ID 

site 

uint8 

application 

uint8 

pdu  type  =  10 

uint8 

entity 

uint8 

entity  type 

uint8 

subtype 

uint8 

status 

uint8 

force  number 

uint8 

appearance 

20  bytes 

spares 

4  bytes 

total  256  bits  (32  bytes) 

Fig.  6-8  Entity  Appearance  PDU 
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6.3.3.24  Complex  Dead  Reckoning  PDU 

The  Complex  Dead  Reckoning  PDU  comprises  all  kinematics  data  of  an  entity.  The  time  stamp  identifies  when 
the  data  is  valid. 

The  LSB  of  the  Position  fields  is  0.01  m. 

The  LSB  of  the  Velocity  fields  is  0.1  m/sec. 

The  LSB  of  the  Acceleration  fields  is  0.1  m/sec2. 

The  orientation  of  the  entity  is  given  in  quaternions. 

The  LSB  of  the  Orientation  fields  are  1/(215  -  1). 

The  LSB  of  the  Orientation  Rates  fields  are  0.001  rad/sec. 

The  LSB  of  the  Orientation  Acceleration  fields  are  0.01  rad/sec2. 


COMPLEX  DEAD  RECKONING  PDU 


total  416  bits  (52  bytes) 

Fig.  6-9  Complex  Dead  Reckoning  PDU 
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6.3.3.2.5  Simple  Dead  Reckoning  PDU 

The  Simple  Dead  Reckoning  PDU  is  a  streamlined  form  of  the  Complex  Dead  Reckoning  PDU,  optimized  for 
the  needs  of  missile  entities.  The  missile  orientation  is  calculated  from  the  extrapolated  velocity  vector.  The 
precision  of  the  orientation  achieved  by  this  method  is  sufficient  for  missiles. 


SIMPLE  DEAD  RECKONING  PDU 

Entity  ID 

site 

uint8 

application 

uint8 

uint8 

Entity  ID 

entity 

uint8 

time  stamp 

uint32 

Position 

X 

int32 

y 

int32 

z 

int32 

Velocity 

Vx 

inti  6 

Vy 

inti  6 

Vz 

int!6 

spare 

inti  6 

total  416  bits  (52  bytes) 

Fig.  6-10  Simple  Dead  Reckoning  PDU 
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63.3.2.6  Radar  PDU 

The  Radar  PDU  contains  information  about  the  use  of  radar  emitters  for  stimulation  of  radar  warning  receivers, 
or  radar  detection  systems.  The  position  of  the  emitter  can  be  obtained  via  the  Sender  ID.  The  Receiver  ID 
contains  the  entity  ID  of  the  receiver  entity. 

The  radar  mode  field  communicates  the  status  of  the  emitter,  e.g.  not  active,  search,  track. 

The  radar  system  type  is  specified  in  the  radar  type  field. 

The  LSB  of  the  frequency  is  1  MHz. 

The  beam  direction/elevation  contains  the  azimuth/elevation  angle  as  seen  from  the  target. 

The  LSB  is  0.001  rad. 

The  beam  strength  field  indicates  the  power  in  dB  with  reference  to  1  Watt/m2  at  the  target. 

The  LSB  is  0.1  dB. 


RADAR  PDU 

Sender  ID 

site 

uint8 

application 

uint8 

pdu  type  =  22 

uint8 

Sender  ID 

entity 

uint8 

Receiver  ID 

site 

uint8 

application 

uint8 

entity 

uint8 

radar  mode 

uint8 

radar  type 

uintl6 

frequency 

uintl6 

beam  direction 

inti  6 

beam  elevation 

intl6 

beam  strength 

inti  6 

spare 

inti  6 

total  160  bits  (20  bytes) 

Fig.  6-11  Radar  PDU 


6-21 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-02 


Final  Report 
6  TRACE  Network  Connectivity 


6.3.3.2.7  Jammer  PDU 

The  Jammer  PDU  contains  information  about  the  use  of  a  jammer  for  jamming  radar,  radar  warning  receivers,  or 
radar  detection  systems.  The  position  of  the  jammer  can  be  obtained  via  the  Sender  ID.  The  Receiver  ID 
contains  the  entity  ID  of  the  receiver  entity. 

The  jammer  mode  field  communicates  the  status  of  the  jammer,  e.g.  active,  not  active. 

The  type  of  the  jammer  is  specified  in  the  jammer  type  field. 

The  LSB  of  the  frequency  is  1  MHz. 

The  heading/elevation  to  jammer  field  contains  the  azimuth/elevation  angle  as  seen  from  the  target. 

The  LSB  is  0.001  rad. 

The  signal  strength  field  indicates  the  power  in  dB  with  reference  to  1  Watt/m2  at  the  target. 

The  LSB  is  0.1  dB. 


JAMMER  PDU 

Sender  ID 

site 

uint8 

application 

uint8 

pdu  type  =  33 

uint8 

Sender  ID 

entity 

uint8 

Receiver  ID 

site 

uint8 

application 

uint8 

entity 

uint8 

jammer  mode 

uint8 

jammer  type 

uintl6 

frequency 

uintl6 

heading  to  jammer 

inti  6 

elevation  to  jammer 

intl6 

signal  strength 

intl6 

spare 

inti  6 

total  1 60  bits  (20  bytes) 

Fig.  6-12  Jammer  PDU 
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63.3.2.8  Flare  PDU 

The  Flare  PDU  contains  information  about  a  flare  bundle  thrown  out  to  mislead  infrared  guided  seeker  heads. 


FLARE  PDU 


Sender  ID  Isite  _ _ Iuint8 


application  _ |uint8 


du  type  =  3 1  |uint8 


Sender  ID  {entity _ |uint8 


timestamp  |uint32 


active  flag  |int32 


[entity  type  =  2000 


launcher  ID  |uint32 


number  of  flares  Iintl6 


flare  type  _ |intl6 


int!6 


light  intensity  number  _ |int!6 


total  224  bits  (28  bytes) 

Fig.  6-13  Flare  PDU 
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6.33.2.9  Chaff  PDU 

The  Chaff  PDU  contains  information  about  a  chaff  bundle  thrown  out  to  mislead  radar  guided  seeker  heads. 


CHAFF PDU 

Sender  ID 

site 

uint8 

application 

uint8 

pdu  type  =  32 

uint8 

Sender  ID 

entity 

uint8 

timestamp 

uint32 

active  flag 

int32 

entity  type  =  3000 

int32 

launcher  ID 

uint32 

number  of  chaffs 

inti  6 

aspect  ratio 

inti  6 

wing  area 

int8 

wing  span 

int8 

air  mass 

inti  6 

total  224  bits  (28  bytes) 

Fig.  6-14  Chaff  PDU 


6333  Differences  from  DIS  Standard 

Comparing  the  Dasa  Protocol  with  the  DIS  Protocol  the  following  essential  differences  can  be  observed: 

■  the  Dasa  Protocol  subdivides  the  description  of  an  entity  into  a  high  frequency  changing  kinematics  part 
(Complex/Simple  Dead  Reckoning  PDU  52/28  bytes)  and  into  a  low  frequency  changing  appearance  part 
(Entity  Appearance  PDU  32  bytes)  whereas  in  DIS  with  every  position  update  the  whole  entity  description 
(Entity  State  PDU  144  bytes  minimum)  must  be  transferred.  By  not  transferring  unnecessary  (redundant) 
data,  less  bandwidth  is  required  by  the  Dasa  protocol. 

■  the  Dasa  Protocol  uses  a  second  order  extrapolation  algorithm  for  orientation  extrapolation  whereas  DIS 
only  uses  a  first  order  extrapolation  algorithm.  The  orientation  extrapolation  improvement  results  in  reduced 
update  rates  and  thus  a  reduced  bandwidth  requirement.  This  characteristic  proved  to  be  very  effective 
especially  during  highly  dynamic  maneuvers  such  as  dog  fights  in  air  combat  scenarios. 

■  in  the  Dasa  Protocol  a  special  streamlined  PDU  for  the  kinematics  missile  data  update  (Simple  Dead 
Reckoning  PDU  28  bytes)  saves  network  bandwidth,  especially  in  the  bandwidth  consuming  engagement 
phase  of  a  complex  air  combat  scenario. 

■  the  Dasa  Protocol  is  more  streamlined  than  the  DIS  Protocol.  For  example,  DIS  requires  24  bytes  to  specify 
position  while  the  Dasa  protocol  requires  only  12  bytes.  The  Dead  Reckoning  Parameter  field  in  the  DIS 
Entity  State  PDU  contains  15  bytes  of  unused  data. 

■  to  communicate,  for  example,  a  landing  gear  state  change  requires  the  transfer  of  an  Entity  Appearance  PDU 
(length  32  Bytes)  when  running  the  Dasa  Protocol.  In  DIS,  160  bytes  are  needed  (Entity  State  PDU  with  one 
Articulation  Parameter)  for  this  information. 

■  Flares  and  Chaff  simulation  in  DIS  would  require  an  Entity  State  PDU  (144  bytes)  for  each  flare/chaff  in  the 
bundle.  In  the  Dasa  Protocol,  28  bytes  are  needed  for  the  whole  flare  or  chaff  bundle. 
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■  all  Dasa  PDU’s  are  of  fixed  length  and  therefore  easy  to  decode.  In  DIS,  many  PDU’s  are  variable  in  size 
and  can  become  very  unhandy  when  being  decoded,  especially  the  Emission  PDU. 


DIS  2.0.4/DIS-Lite 

Dasa 

Ethernet  Header 

First  22  bytes 

Ethernet  Header 

First  22  bytes 

IP  Header 

Next  20  bytes 

IP  Header 

Next  20  bytes 

U DP  Header 

Next  8  bytes 

UDP  Header 

Next  8  bytes 

1  PDU  Header 

Dasa  Header  j 

Protocol  Version 

1  byte  (4) 

Dasa  site 

1  byte  (Ob  =  Germany, 

0c  =  US) 

Exercise  ID 

1  byte 

Dasa  Application 

1  byte 

PDU  Type 

1  byte  (1-27  DIS, 

28-31  DIS-Lite) 

Dasa  Type 

1  byte 

(1,2,10,11,12,20,21) 

Padding 

1  byte 

Dasa  Entity 

1  byte 

Remaining  Fields 

Same  as  usual/varies  by 

_ &E£ _ 

Remaining  Fields 

Same  as  usual/varies  by 
type 

Table  6-3:  DIS/DIS-Lite/Dasa  Comparisons 


6.4  Networking  Experiments  [Dasa  &  AFRL1 
6.4.1  Evaluation  of  the  transfer-media tDasa] 

The  following  transfer  media  were  used  for  the  transatlantic  network 
<=>  Standard  ISDN-telephone  line 
<=>  DSI  (connected  via  ISDN) 


For  the  evaluation  of  the  media,  Dasa  took  measurements  with  simple  tools  to  determine  technical  data  such  as 
usable  bandwidth  and  media  specific  delay  times. 


Table  6-4  Media  Cost 


Houston  Associates  Incorporated,  the  operator  of  the  DSI,  could  not  explain  why  the  DSI  performance  was  so 
bad.  It  is  possible  that  the  non-standard  means  by  which  Dasa  connected  to  the  DSI  (dial-up  ISDN  line  between 
Dasa  and  Stuttgart)  may  attribute  to  its  poor  performance.  The  normal  connection  has  a  T-l  line  (1.55  Mbit/sec) 


6-25 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc. -No.:  Dasa-S-R- 1775-02 


Final  Report 
6  TRACE  Network  Connectivity 


between  the  user  and  DSI  hub.  A  more  detailed  analysis  is  not  possible  without  the  help  of  the  supplier  since 
Dasa  AND  VACD  had  no  information  about  the  modifications  and  systems  used  including  the  ISDN  terminal 
adapter  installed  at  the  DASA  laboratories. 

The  fixed  cost  for  the  DSI  was  $7700/month  plus  $2500  for  installation.  The  costs  of  the  ISDN  telephone 
connection  to  Stuttgart  must  be  added.  This  ISDN  line  had  to  be  set  up  at  least  one  hour  in  advance  of  DSI 
usage  and  must  not  be  disconnected  during  the  run  to  ensure  proper  functionality. 

The  support  was  slow  and  the  connection  could  only  be  set  up  on  request  of  AFRL  since  the  DSI  was  an 
experimental  network  being  developed  by  the  US  government  to  support  networked  simulations. 


6.4.2  Preliminary  Network  Delay  Tests  [AFRL1 


HKJV  -- 

n 

loO  -- 

160  -- 

■  r 

□  DIS  Average  (D-W) 

■  DIS  Average  (W-D) 

□  DASA  Average  (D-W) 

□  DASA  Average  (W-D) 

■  DIS-Lite  Average  (D-W) 

□  DIS-Lite  Average  (W-D) 
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Fig.  6-15  DSI  Network  Delays 


30-Oct-96  20-May-97  20-May-97  20-May-97  20-May-97 


□  DIS  Average  (D-W) 

■  DIS  Average  (W-D) 

□  DASA  Average  (D-W) 

□  DASA  Average  (W-D) 

■  DIS-Lite  Average  (D-W) 

□  DIS-Lite  Average  (W-D) 


Fig.  6-16  ISDN  Network  Delays 


6.4.3  End-to-End  Tests  [AFRL] 

Two  types  of  end-to-end  tests  were  performed  using  SNAP.  The  first  was  simply  a  network  transit  delay.  In 
this  test  SNAP  time-stamped  all  transmitted  and  received  PDU  traffic.  This  time-stamped  data  could  then  be 
analyzed  to  determine  network  transit  delays  and  to  some  degree  bandwidth  requirements. 
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The  second  test  was  a  complete  end-to-end  test.  This  test  required  SNAP  to  input  a  signal  to  one  of  the  two 
site’s  simulators.  SNAP  with  EVDAS  would  then  sample/record  and  time-stamp,  using  GPS  time,  data  at 
various  points  along  the  simulation  process.  Data  was  taken  at  the  stick  input,  SCRAMNet  for  state  variable 
data  at  both  sites,  visual  output  at  both  sites,  and  at  the  input  from  the  ISDN  router  (LAN)  side  at  both  sites. 
This  recorded  and  time-stamped  data  could  then  be  analyzed  to  give  the  amount  of  time  it  takes  for  a  simulation 
to  process  data.  The  results  of  these  tests  are  presented  below. 
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DIS  Protocol 
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The  analysis  of  this  data  is  at  times  very  subjective.  SNAP  saves  the  data  in  tab  deliminated  text  form.  To 
analyze  it  it  is  imported  into  Excel  and  plotted.  Changes  in  the  plots  show  where  the  variables  change.  If  the 
data  plots  are  noisy,  little  to  no  information  is  available  .  Where  possible  a  best  judgement  call  was  made  to 
determine  at  what  point  the  state  changed.  Sample  plots  of  SNAP  data  are  shown  below.  In  all  instances  the  X 
label  indicates  the  GPS  timestamp  for  each  data  point. 


Figure  6-17  shows  one  example  of  the  graphs  used  to  determine  the  time  at  which  the  stick  input,  the  roll  state 
variable  and  the  roll  rate  state  variable  changed.  The  labeled  points  indicate,  for  this  run,  the  points  chosen. 
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Fig.  6-17  Dasa:  Dasa  Driving  Stick 

DASA  Protocol  -  DASA  Driving  Stick 
EVDAS  Roil  Plot 
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Figure  6-18  again  shows  an  example  of  the  type  of  graph  used  to  determine  the  point  at  which  the  pilots  visual 
display  would  indicate  a  change  in  his  attitude.  The  three  labelled  points  indicate  that  the  point  was  not  easily 
chosen.  For  this  run,  the  point  with  the  timestamp  label  of  48426.53597  was  chosen. 


Figure  6-19  shows  another  example  of  the  type  of  graph  used  to  determine  when  the  pilots  visual  display 
changed,  showing  the  Dasa  aircrafts  attitude  change  on  the  AFRL  simulation’s  visual  display.  This  plot  and 
figure  6-18  both  come  from  data  collected  from  EVDAS. 
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Fig.  6-20  DIS-Lite:  AFRL  Driving  Stick 

Figure  6-20  shows  a  time  correlated,  combined  plot  of  the  stick  input,  EVDAS  (visual  system  changes),  and  the 
roll  and  roll  rate  state  variabe  changes.  This  better  shows  the  result  of  a  single  SNAP  run.  The  stick  signal  is 
input  to  the  simulator  by  SNAP.  This  is  followed  by  a  roll  and  roll  rate  change  which  is  followed  by  a  visual 
system  change  (EVDAS).  The  plot  graphically  shows  the  delay  between  each  reaction  to  the  stick  input  signal. 

Figures  6-21  shows  an  example  graph  used  to  determine  when  the  Dasa  simulation  showed  the  attitude  change 
for  the  AFRL  aircraft. 

Figure  6-22  shows  an  example  of  the  graphs  used  to  determine  when  the  roll  rate  for  the  AFRL  aircraft  was 
updated  in  the  Dasa  simulation. 
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DIS-Lite  -  AFRL  Driving  Stick 
DASA  EVDAS  Roll  Plot 
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Fig.  6-21  DIS-Lite:  Dasa  EVDAS  Roll  Plot 


Fig.  6-22  DIS-Lite:  AFRL  Driving  Stick  /  Dasa  Roll  Rate 
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6.4.4  Head-to-Head  comparison  of  the  DIS-  and  Dasa-Protocol [Dasal 

The  two  protocols  primarily  used  for  simulator  networking  in  the  TRACE  program  were  the  DIS-  and  the  Dasa 
protocols.  In  addition  to  the  subjective  evaluation  of  experienced  pilots,  the  end  user,  an  objective  evaluation  of 
the  system  and  performance  data  should  be  done.  In  this  chapter,  a  head-to-head  comparison  was  done  by 
measuring  the  position  and  flight  angle  error  of  a  transferred  aircraft  using  simple  but  directly  comparable  flight 
maneuvers. 

6.4.4.1  The  Test  Configuration 

A  flight  path  was  recorded,  which  could  be  replayed  several  times  under  different  test  configurations  and 
conditions.  The  data  recorder  had  access  to  the  DASA  simulator’s  NIC  interface  and  all  changes  in  data 
belonging  to  the  simulated  aircraft  were  time  stamped  and  recorded. 

For  the  measurements,  the  data  recorder  played  the  data  back  to  the  simulator’s  NIC-interface  which  simulates  a 
connected  simulated  aircraft  for  the  NIC. 

Since  the  measurements  lasted  for  several  days,  influences  of  external  media  (such  as  ISDN)  were  excluded  by 
using  local  Ethernet  connections.  For  control  reasons  a  complete  simulator  was  connected  to  the  receiving  NIC 
and  the  replayed  aircraft  was  displayed  on  the  visual  system.  It  was  verified  that  the  connected  simulator  had  no 
influence  on  the  measured  data.  The  data  recorder  again  has  access  to  the  simulator’s  NIC  interface  and 
recorded  the  transferred  aircraft’s  changing  data  together  with  a  time  stamp.  The  synchronization  of  the  time 
base  was  done  by  using  the  time  signal  from  the  GPS  (Global  Positioning  System),  as  it  is  done  for  the  WAN- 
connection. 


Fig.  6-23  Test  Configuration 


The  influences  of  the  delay  times  as  a  result  of  the  transatlantic  distances  were  simulated  by  a  delay  tool ,  which 
enables  arbitrary  delay  times  (distances)  to  be  produced.  Because  such  a  tool  needs  processing  time  and 
therefore  influences  itself  too,  it  was  always  integrated  in  the  test  configuration. 
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The  following  tests  were  performed 

•  no  extrapolation  at  the  receiving  site,  0msec  delay  time 

=>  these  data  sets  are  recognizable  and  were  really  transmitted  and  represent  the  basis  for  the  extrapolation 
to  the  original  flight  path. 

•  with  extrapolation  at  the  receiving  site,  0msec  delay  time 

from  which  the  quality  of  the  extrapolation  to  the  original  flight  path  can  be  recognized 

•  with  extrapolation  at  the  receiving  site,  100msec  delay  time 

from  which  the  influence  on  the  distance  caused  by  the  delay  time  can  be  recognized 

•  all  measurements  were  performed  with  both  the  DIS-  and  Dasa-Protocol 
from  which  the  differences  using  the  protocols  become  visible. 


The  recorded  data  sets  were  transformed  into  ASCII  text  files  and  imported  into  MS-EXCEL  for  analysis. 

6.4 .4.2  Data  Regeneration 

The  referencing  flight  path  consists  of  a  normal  and  a  hard  right  and  left  turn.  This  flight  maneuver  shows  how 
the  different  rates  of  acceleration  or  change  in  target  speed,  angle  or  position  influence  the  procedure  used  for 
transmission.  The  following  graph  shows  the  X-  and  Phi-values  (position  and  attitude).  The  results  can  be 
reflected  on  all  coordinates  and  angles. 


Fig.  6-24  Reference  Flight  path  and  Transmitted  Values 


Fig.  6-24  shows  the  X-value  of  the  reference  flight  path.  For  comparison,  the  different  protocols’  transmitted 
data  are  printed  using  different  colors  and  shapes.  The  measurements  show  that  the  transmitting  algorithms 
accuracy  parameters  for  both  protocols  were  chosen  correctly,  thus  the  transferred  data  rate  when  compared  to 
the  originally  produced  data  from  the  data  recorder  (simulating  the  simulator)  was  reduced  by  70%  on  both 
protocols. 
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Fig.  6-25  Regenerated  Flightpath  in  Comparison  to  the  Referenced  Flightpath 


Fig.  6-25  shows  the  regenerated  flight  paths  for  both  protocols  at  the  receiving  site  with  a  delay  of  100msec  as 
compared  to  the  referenced  flight  path.  The  diagram  clearly  shows  the  deviation  of  the  extrapolated  from  the 
referenced  flight  path.  As  soon  as  a  new  data  set  is  received  the  regenerated  curves  gets  corrected  to  the  actual 
value. 
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6AA.3  Evaluation  of  the  Absolute  Positioning  Error 

To  compute  the  transmitting  procedure’s  absolute  error,  the  regenerated  and  the  referenced  values  are  subtracted 
from  each  other.  The  absolute  values  of  the  result  can  be  graphically  shown. 


Fig.  6-26  Absolute  Positioning  Error 

The  positioning  error  caused  by  the  reduced  data  transfer  differs  just  trivially  between  the  protocols.  A  closer 
look  shows  the  error  of  the  regenerated  Dasa-Protocol  values  to  be  a  bit  better.  The  influence  of  the  100msec 
delay  time  is  obvious  and  is  characteristic  of  the  transatlantic  distance. 

The  computed  absolute  positioning  error  stays  within  the  preset  values  as  long  as  there  is  no  added  delay  time. 
By  adding  the  transatlantic  delay,  the  error  is  multiplied  by  factor  of  3.  The  highest  absolute  error  value  never 
exceeds  0.5  meter  (in  comparison:  the  aircraft  moves  about  33  meters  when  traveling  at  Mach  1  as  it  did  in  these 
tests). 
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6A.4.4  Evaluation  of  the  Absolute  Flight  angle  Error 

To  compute  each  transfer  procedure’s  absolute  anglular  error,  the  regenerated  angles  are  subtracted  from  the 
referenced  angles  and  the  resulting  absolute  values  can  be  plotted. 


Fig.  6-27  Absolute  Angle  Error 


The  regenerated  DIS-data  errors  differs  from  the  reference  angle  values  more  than  the  regenerated  Dasa-data. 
Again,  the  additional  100msec  delay  caused  higher  error  values  and  again  by  a  factor  of  3. 
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6AA.5  Required  Bandwidth 

The  required  bandwidth  for  networked  flight  simulations  is  another  interesting  point  to  consider,  since  hardware 
must  be  bought  or  leased  that  can  support  these  requirements.  The  following  measurements  of  bandwidth 
requirements  for  the  DIS-  and  Dasa-  protocol  depicts  the  requirements  for  one  networked  entity  (aircraft)  with 
its  position  and  angle  data.  The  influences  of  additional  weapon  systems,  such  as  missiles  and  EW,  are  not 
taken  into  account  in  this  analysis. 


DIS’DASA’Compare 


Daimler-Benz  Aerospace 


DASA ----- -DIS  -  -  -  X  (org)  1  1  Tn~  10  per  moving  avcrapc(DASA)  ~~~^'10permovingaverapc(DIS)  j 


Fig.  6-28  Comparison  of  the  Bandwidth  Need 


The  diagram  clearly  shows  a  50%  reduction  in  the  required  bandwidth  using  the  Dasa-Protocol  as  compared  to 
the  DIS-Protocol  when  using  the  same  scenario  with  identical  flight  paths.  The  averaged  lines  in  the  diagram 
illustrate  this  more  clearly.  Also,  the  peak  data  rate  values  of  DIS  are  quite  high,  making  it  difficult  to 
extrapolate  the  bandwidth  needs  for  increasing  numbers  of  aircraft.  Additionally,  this  may  cause  short  period 
bandwidth  limitations,  even  if  the  requirements  were  properly  estimated.  Furthermore,  the  use  of  weapon 
systems  and  models,  i.e.  high  frequency  missile  models,  will  cause  an  increase  in  the  bandwidth  needed  for  both 
protocols.  Because  these  results  are  based  on  a  very  simple  scenario,  the  rehearsal  oriented  bandwidth  need 
must  be  evaluated  under  more  complex  scenarios  even  if  they  are  not  directly  comparable. 


6.4.5  Production  Run  Bandwidth [Dasa] 


6.4.5.1  Dasa  PDU-Statistics 

During  the  Production  Runs,  the  following  data  were  recorded  for  analyzing  bandwidth  usage  and  protocol 
features  and  quality: 

■  the  number  of  PDU-packages  used,  for  all  three  protocol  types 

■  the  number  of  active  aircraft 

■  the  number  of  active  missiles 

■  the  bandwidth  used 
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Both  input  and  output  data  were  recorded.  The  output  data  represents  the  value  sent  to  ensure  adequate  results 
at  the  receiving  site.  The  input  data  represents  the  value  the  Dasa  simulation  actually  received  from  the  AFRL 
simulation.  Due  to  the  ISDN  bandwidth  limitations  of  120  kbit/sec,  the  measured  datarate  on  the  input  line 
cannot  exceed  120  kbit/sec  which  may  restrict  the  explicit  number  of  received  PDU’s.  Therefore,  the  analysis 
performed  on  the  measurements  is  based  on  the  output  data. 


In  this  chapter  the  Dasa-measurements  during  the  Production  Runs  will  be  discussed  in  detail. 

Mainly,  the  following  four  points  of  interest  were  analyzed: 

•  the  used  datarate 

Complex  scenario  data  connections  bandwidth  requirements  are  very  important  since  they  tend  to  drive  cost. 
There  are  always  the  input  and  output  values  to  look  at  because  of  differences  in  the  implementation  of  the 
Dasa  NIC  and  implementation  of  the  DIS/DIS-Lite-NIC  at  Air  Force  Research  Laboratory  and  Daimler-Benz 
Aerospace  AG. 

•  the  required  bandwidth  as  a  function  of  the  number  of  active  entities 

The  influence  the  number  of  entities  has  on  bandwidth  requirements  indicates  how  to  extrapolate  bandwidth 
requirements  for  more  complex  scenarios  from  simple  ones. 

•  the  provided  PDU-types  usage 

Another  important  point  is  to  determine  which  type  of  PDU  is  used  most  often  or  needed  to  fulfill  the  needs 
of  a  successful  wide  area  networked  simulation. 

•  the  information  dispersion  of  the  PDU-types 

A  percentage  diagram  of  the  quantity  of  each  PDU-type  as  a  function  of  the  number  of  PDU  s  sent  is  needed. 


Different  types  of  PDU’s  are  used  to  fulfill  the  requirements  of  the  TRACE-scenarios. 
The  Dasa-PDU’s  are: 

•  CMD 

•  EAP 

•  SDR 

•  CDR 

•  RAD 

•  DEX 

The  DIS-PDU’s  are 

•  ES  -  contains  entity  state  information 

•  FIR  -  contains  information  about  a  launched  missile 

•  DET  -  contains  information  about  a  missile  removal  (hit  or  miss) 

•  EMI  -  contains  emission  data  for  warning  receiver 

•  CMD  -  not  used  in  DIS 

•  EAP  -  not  used  in  DIS 


-  contains  command  and  control  data 

-  contains  the  appearance  and  other  low  update  rate  data  for  an  entity 

-  contains  the  dead  reckoning  data  for  a  simple  entity  (e.g.  missiles) 

-  contains  the  dead  reckoning  data  for  a  complex  entity 

-  contains  the  information  for  a  radar  warning  receiver 

-  contains  general  information  from  entity  to  another 


The  DIS-Lite-PDU’s  are: 

QR 

-  contains 

KINE 

-  contains 

FIR 

-  contains 

DET 

-  contains 

EMI 

-  contains 

CMD 

-  not  used 

the  relatively  static  information  about  the  entity  state 
kinematics  information  about  the  entity  state 
information  about  a  launched  missile 
information  about  a  missile  removal  (hit  or  miss) 
emission  data  for  warning  receiver 
in  DIS-Lite 
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During  the  Production  Runs,  the  pilots  could  not  differentiate  between  the  protocols  as  long  as  bandwidth 
limitations  did  not  effect  the  quality  of  the  simulation.  If  adequate  quality  could  not  be  maintained  using  a 
particular  protocol,  it  wouldn’t  be  used  in  later  runs. 

6.4.5.1.1  Scenario  2:  1  v  1  Combat 

In  this  scenario,  two  manned  cockpits,  equipped  with  complete  weapon  systems,  are  placed  in  opposition.  These 
hostile  entities  perform  combat  with  the  objective  to  kill  the  opponent. 

6.4.5. 1.1.1  DIS-Protocol 

6.4.5. 1 .1.1.1  Bandwidth 


6.4.5. LI. 1.1.1  Bandwidth  Usage 


Fig.  6-29  S2-DIS-  Used  Bandwidth 


The  diagram  shows  that  a  bandwidth  of  approximately  5  to  25  kbit/sec  is  needed  for  scenario  S2.  The  difference 
between  the  input  and  output  values  comes  from  the  different  behavior  of  the  pilots  (the  AFRL-pilot  is  more 
maneuverable  in  this  phase). 

The  diagram  shows  about  150  seconds  of  approach  before  the  combat  phase  begins. 
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6.4.5.  LI. 1.1.2  Bandwidth  as  a  function  of  the  number  of  entities 


Fig.  6-30  S2-  DIS-  Used  Bandwidth/#Entities 


The  diagram  above  shows  the  required  bandwidth  for  the  output  of  the  Dasa  simulator  as  a  function  of  the 
number  of  active  entities.  The  small  AC  line  represents  the  number  of  aircraft  (in  this  scenario  there  is  1  aircraft 
on  both  AFRL  and  Dasa  sides).  In  scenario  S2,  Dasa  is  responsible  for  1  aircraft  and  its  missiles.  The  line  for 
the  number  of  active  missiles  is  added  to  the  line  for  the  number  of  aircraft.  Therefore,  the  wide  line  represents 
missiles  +  aircraft  =  overall  number  of  represented  entities 

Between  10  and  20  seconds,  the  number  of  missiles  and  aircraft  drops  to  zero  due  to  Dasa  resetting  its 
simulation.  As  you  can  see,  the  bandwidth  drops  to  zero. 

At  about  time  =  160  seconds,  the  combat  phase  begins.  The  number  of  missiles  on  the  Dasa  simulation 
increases  from  0  to  1  and  then  to  2.  As  the  first  missile  burned  out,  the  number  of  missiles  drops  again  to  1 
before  the  second  missile  hits  the  AFRL  target. 

As  the  each  missile  is  launched,  the  bandwidth  increases  to  allow  the  data  for  the  new  high  speed  entity  to  be 
continuously  transferred.  With  both  missiles,  the  bandwidth  requirement  is  up  to  25  kbit/sec  but  drops  as  the 
missiles  bum  out  and  are  removed. 

When  just  one  aircraft  is  active,  there  is  a  constant  need  for  a  bandwidth  of  approximately  5  kbit/sec. 
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6.4.5. 1 .1.1.2  PDU-Statistics 


6.4.5. 1. 1. 1.2. 1  Number  of  PDU's  as  a  Function  of  the  Number  of  Entities 


Fig.  6-31  S2-  DIS-  #Entities/#PDU,s 

This  diagram  above  shows  the  PDU-types  needed  for  correct  data  transfer  and  regeneration  at  the  connected  site 
as  a  function  of  number  of  active  entities.  Again,  the  number  of  active  missiles  and  active  aircraft  are  added.  In 
this  scenario,  the  Dasa  simulator  is  responsible  for  only  one  aircraft. 

As  before,  the  reset  of  the  Dasa  simulator  and  the  onset  of  the  combat  phase  with  the  launching  of  missiles  can 
clearly  be  seen. 

While  the  aircraft  approach  one  another,  some  ES-PDU’s  (Entity  State)  and  some  EMI-PDU’s,  representing  the 
radar  emission  of  the  aircraft’s  radar  model,  are  transmitted. 

As  the  first  missile  is  launched,  one  FIR-PDU’s  (Fire-PDU)  is  sent  and  the  number  of  ES-PDU’s  increases  due 
to  the  transmission  of  data  for  the  new  high  speed  entity. 

The  EMI-PDU’s  increase  because  of  the  emissions  of  the  missile’s  seeker  head. 

As  the  missile  is  removed,  the  DET-PDU  (Detonation-PDU)  is  sent  to  indicate  the  reason  a  it  was  removed. 


6-42 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-02  _ 

6.4.5. 1. 1. 1.2.2  Assignment  of  PDU -Types  over  one  Complete  Run 


Final  Report 
6  TRACE  Network  Connectivity 


Fig.  6-32  S2-  DIS  PDU-Percentage 


The  diagram  shows  that  the  ES-PDU  (Entity-State)  and  the  EMI-PDU  (Emission-PDU),  which  holds  the 
scenario’s  radar  information,  use  the  majority  of  the  bandwidth  with  the  ES-PDU  having  the  largest  demand  on 
bandwidth.  Also,  for  each  missile  launched,  firing  information  (FIR-PDU)  and  detonation  information  DET- 
PDU  (Detonation-PDU  indicates  the  reason  missile  was  removed)  is  sent. 
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6.4.5.  LI. 2  DIS-Lite-Protocol 
6.4.5. 1 . 1 .2. 1  Bandwidth 

6.4.5.  1.  1.2. 1.1  Bandwidth  Usage 


Fig.  6-33  S2-  DIS-Lite-  Used  Bandwidth 

The  diagram  above  shows  the  bandwidth  usage  for  scenario  S2  using  the  DIS-Lite-protocol.  The  value  of  the 
input  is  again  higher  in  comparison  to  the  output  because  of  time  synchronization  as  discussed  above. 

During  the  approach  phase,  a  bandwidth  of  3  to  5  kbit/sec  is  needed  to  transmit  the  required  data  from  each 
simulation.  In  the  combat  phase,  which  starts  about  time  =  90  seconds,  the  bandwidth  need  increases  by  10 
kbit/sec  to  15  kbit/sec  for  the  incoming  line  because  of  launched  missiles  and  more  agile  aircraft. 

The  high  peak  in  bandwidth  on  the  “Wan-In“-line  is  a  result  of  the  tailspin  after  a  missile  hit  on  the  AFRL-target 
which  causes  the  dead  reckoning  algorithm  to  transfer  very  high  frequency  entity  state  information.  The 
movement  of  a  dead  entity  can  cause  problems  if  the  bandwidth  limits  of  the  transfer  media  is  reached. 
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6A.5. 1.1.2. 1.2  Bandwidth  as  a  function  of  the  number  of  entities 


Fig.  6-34  S2-  DIS-Lite-  Used  Bandwidth/#Entities 


For  a  closer  look  at  how  bandwidth  depends  on  the  number  of  active  entities,  the  diagram  shows  the  amount  of 
outgoing  information  drawn  with  respect  to  the  additive  number  of  entities. 

During  the  approach  phase,  the  Dasa  simulation  aircraft  needs  a  relatively  constant  3  kbit/sec  bandwidth.  As  a 
missile  is  launched,  the  bandwidth  need  increases  to  fulfill  the  required  information  exchange  for  the  newly 
created  high  speed  target.  Once  the  missile  flies  the  precalculated  flight  path,  the  bandwidth  required  drops 
again  from  8  kbit/sec  to  4  kbit/sec.  As  the  next  missile  is  launched  by  the  Dasa-simulator,  there  is  again  a 
bandwidth  increase  to  8  kbit/sec  but  this  time  it  does  not  decrease  after  the  first  missile  is  removed.  The  reason 
for  the  bandwidth  not  decreasing  is  the  hit  on  the  target.  After  all  missiles  are  removed  the  returns  to  the  normal 
level  (approach  phase  level). 


6-45 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc. -No.:  Dasa-S-R- 1775-02 


Final  Report 
6  TRACE  Network  Connectivity 


6.4.5. 1 . 1 .2.2  PDU-Statistics 

6.4.5. 1.1. 2.2.1  Number  ofPDU’s  as  a  Function  of  the  Number  of  Entities 


S2:  DIS-Lite  ■  #Entities/#PDU's 
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Fig.  6-35  S2-  DIS-Lite-  #Entities/#PDU,s 

The  approaching  entity’s  state  is  transferred  by  a  small  number  of  EMI-PDU’s,  containing  the  emission  data, 
and  a  few  KINE-PDU’s  containing  the  dynamic  information  about  the  entity  state.  The  radar  was  not  active  at 
the  very  beginning  and  was  switched  on  after  a  few  seconds.  As  a  missile  is  launched,  a  FIR-PDU  is  sent 
indicating  the  launch,  some  QR-PDU’s  are  sent  containing  the  relatively  static  entity  state  information  and 
KINE-PDU’s  are  sent  for  high  dynamic  data  exchange.  Because  missiles  are  high  speed  entities,  information  is 
transferred  at  a  high  rate. 

The  high  rate  of  KINE-PDU’s,  after  time  =  170  seconds,  are  the  result  of  a  missile  avoidance  maneuver  by  the 
Dasa- aircraft  and  is  the  reason  for  the  increase  of  EMI-PDU’s,  which  transfers  the  IR  information  in  the  DIS  and 
DIS-Lite-  protocols.  Agile  maneuvers  with  use  of  afterburners  cause  the  need  for  IR-  information  exchange. 

For  some  unknown  reason,  the  implementation  of  the  DIS-Lite  protocol  was  sending  EMI-PDUS  to  entities  that 
had  already  been  removed  from  the  scenario,  which  doesn’t  occur  when  using  the  other  protocol. 
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6.4.5. 1.1. 2.2.2  Assignment  of  PDU -Types  over  one  Complete  Run 


Fig.  6-36S2-  DIS-Lite  PDU-Percentage 


Quantitatively,  the  KINE-PDU’s  transfer  most  of  the  data  exchanged  and  are  supported  by  a  small  number  of 
QR-PDU’s,  which  contain  the  rest  of  the  entity  state  information. 

The  emission  information  is  the  second  largest  user  of  bandwidth,  accounting  for  a  quarter  of  the  transferred 
data  packages. 

For  each  missile  launched,  FIR-  and  DET-PDU’s  were  sent  to  inform  the  partner  about  the  new  or  removed 
target. 
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6.4.5. 1. 1.3  Dasa-Protocol 

6.4.5. 1 . 1 .3. 1  Bandwidth 

6.4. 5. 1.1.3. 1.1  Bandwidth  Usage 


S2:  DASA-  Used  Bandwidth 


Fig.  6-37  S2-  Dasa-  Used  Bandwidth 

As  previously  discussed,  the  value  of  the  incoming  data  is  higher  than  that  of  the  outgoing  as  a  result  of  better 
time  synchronization  at  the  Dasa  site. 

During  the  approach  phase,  one  entity  on  each  site  needs  about  2  kbit/sec  of  bandwidth  (4  kbit  for  the  input 
data).  There  is  a  slight  increase  in  the  bandwidth  needed  (to  about  3  kbit/sec)  as  the  combat  phase  begins  at  t  = 
120  seconds. 

There  is  no  explanation  for  the  peak  at  t  =  100  seconds. 

At  t  =  300  seconds,  the  effect  of  a  tailspin  from  the  AFRL  side  can  again  be  seen.  This  tailspin  causes  a  high 
rate  of  data  to  be  exchanged  because  of  its  incalculable  movements.  In  effect,  it  doubles  the  bandwidth  required 
for  that  period  of  time  and  can  cause  problems  if  the  bandwidth  limitations  are  exceeded. 
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6.4.5. 1.1.3. 1.2  Bandwidth  as  a  function  of  the  number  of  entities 


S2:  DAS  A  -  Bandwidth/#Entities 


t/sec 


WanOut - AC  — — M 


Fig.  6-38  S2-  Dasa-  Used  Bandwidth/#Entities 

During  the  single  entity’s  approach  phase,  a  bandwidth  of  1  to  2  kbit/sec  is  needed.  As  the  combat  phase  begins 
and  two  missiles  are  launched,  the  required  bandwidth  increases  to  3  kbit/sec.  In  the  second  launch  period  at  t  = 
240  seconds,  the  single  launched  missile  is  covered  by  a  datarate  of  2  kbit/sec. 

Even  this  diagram  gives  no  explanation  for  the  peak  in  bandwidth  usage  at  t  =  100  seconds.  There  is  no  change 
in  the  number  of  entities  which  could  cause  this  effect. 
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6.4.5. 1 . 1 .3.2  PDU-Statistics 

6.4.5.1.1.3.2.1  Number  of  PDU’s  as  a  Function  of  the  Number  of  Entities 


S2:  DAS  A  -  #Entities/#PDU's 
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Fig.  6-39  S2-  Dasa-  #Entities/#PDU's 

During  the  approach,  the  single  aircraft  requires  only  a  few  EAP-PDU’s  (Entity  Appearance)  and  a  few  CDR- 
PDU’s  (Complex  Dead  Reckoning)  to  describe  its  state. 

To  handle  the  radar  systems  emission  information,  a  constant  amount  RAD-PDU’s  (Radar-PDU)  is  exchanged. 

At  the  moment  the  first  missile  is  launched,  the  number  of  EAP- PDU’s  increases  and  a  few  SDR-PDU’s 
(Simple  Dead  Reckoning),  containing  the  missile  kinematics  data,  are  sent  to  the  other  simulator. 

Immediately  after  the  second  missile  is  launched  the  aircraft  performed  a  evasive  maneuver  causing  the  number 
of  CDR-PDU’s  to  increase.  These  PDU’s  describe  the  aircraft’s  kinematics. 

Notice  that  as  the  missiles  disappear,  the  number  of  all  PDU-types  decrease. 

The  second  missile  launch  period  confirms  the  results  as  well. 

This  diagram  shows  that  the  spike  in  the  bandwidth  observed  in  the  previous  diagrams  is  caused  by  a  high 
number  of  CDR-PDU’s.  Since  these  PDU’s  describe  the  state  of  the  aircraft,  the  resultant  spike  may  be  the 
result  of  high  dynamic  movements  of  the  aircraft  such  as  sudden  rolls  and/or  dives. 
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6.4.5. 1.1. 3.2.2  Assignment  of  PDU-Types  over  one  Complete  Run 


S2 :  DASA  -  PDU-Averaae 
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Fig.  6-40  S2-  Dasa  PDU-Percentage 

Notice,  in  the  diagram,  that  the  quantity  of  EAP-  and  CDR-PDU’s  sent  are  nearly  equal.  Additionally,  some 
SDR-PDU’s,  transferring  missile  relevant  information,  are  sent  as  a  result  of  firing  missiles. 

The  RAD-PDU’s,  which  contain  radar  warning  receiver  data,  complete  the  diagram. 

6.4. 5. 1.1. 4  Protocol  Comparison 

Cnmnarixnn  DIS~/DASA-/DIS-Lite-Protocol 


_ w*n_out  <  dzs-lic«)  . .  10  per  moving  average  (Wan_Out  (DIS» 

-  10  per  moving  average  (Wan_Out  (DASA)) _ _  10  per  moving  average  (Wan.Out  (DIS-Lite)) 


Fig.  6-41  S2  Protocol  Comparison 


The  diagram  above  compares  the  bandwidth  used  by  each  protocol  during  scenario  S2.  The  graphs  are  not 
directly  comparable  since  the  pilots  learned  from  each  run  and  changed  their  tactics  for  the  next  run.  However, 
the  plots  do  give  a  relative  idea  of  how  the  average  bandwidths  required  by  each  protocol  would  compare.  For 
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the  analysis,  runs  with  similar  complexity  were  chosen,  especially  where  the  number  of  entities  were  concerned. 
The  runs  were  not  identical  but  the  scenario  and  its  complexity  were  the  same. 

To  get  a  better  idea  of  the  values,  a  moving  average  with  a  period  of  10  was  calculated  for  each  recorded  line. 

Notice  that  the  DIS-Protocol  is  erratic  and  has  the  highest  bandwidth  requirements,  with  maximum  averaged 
rates  of  up  to  20  kbit/sec  and  a  measured  peak  bandwidth  requirements  out  to  30  kbit/sec. 

Notice  also,  that  the  DIS-Lite-protocol  is  also  very  erratic  but  that  its  bandwidth  requirements  are  approximately 
one  third  that  of  the  DIS-Protocol. 

The  Dasa- Protocol  shows  a  smoother  behavior  (less  variation  between  peaks  and  valleys)  and  a  lower  bandwidth 
requirement.  The  averaged  line  shows  the  required  bandwidth  for  the  Dasa-Protocol  to  be  one  third  that  of  the 
DIS-Lite-protocol’ s  and  one  ninth  that  of  the  DIS-protocoFs. 

All  measurements  depict  a  low  datarate  during  the  approach  phases  and  a  steady  increase  in  required  bandwidth 
when  missiles  are  added  to  the  scenario  during  combat  phase. 


Protocol  v 

average  bandwidth  need 

peak  bandwidth  need 

DIS 

DISLite 

Dasa 

<20  kbit/sec 

<7  kbit/sec 

<3kbit/sec 

<30  kbit/sec 

<10  kbit/sec 

<3kbit/sec 
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6.4.5.1.2  Scenario  3:  2  v  2  Combat 

In  this  scenario,  two  hostile  forces  each  consisting  of  two  manned  cockpits  equipped  with  full  weapons  systems 
were  generated.  The  objective  was  to  destroy  the  hostile  force  using  MRMs  and/or  SRMs. 

6.4.5. 1.2.1  DIS-Protocol 

6.4 .5. 1.2. 1.1  Bandwidth 

6.4.5. 1.2. 1.1.1  Bandwidth  Usage 

S3:  PIS-  Used  Bandwidth 
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Fig.  6-42  S3-  DIS-  Used  Bandwidth 

The  diagram  shows  that  a  bandwidth  of  approximately  20  to  120  kbit/sec  is  needed  for  scenario  S3.  The 
differences  between  the  input  and  output  values  come  from  the  difference  in  pilot  behavior  and  use  of  weapons 
(this  time,  the  Dasa-pilots  were  more  maneuverable  and  launched  more  missiles  in  a  short  period  of  time); 
therefore,  input  and  output  values  are  not  directly  comparable. 

Since  more  aircraft  are  involved  in  this  scenario,  the  approach  phase  is  not  as  evident  as  in  scenario  S2. 

The  high  bandwidth  requirement  shown  on  the  input  line  (Wan_In),  at  about  t  =  500  seconds,  was  caused  by  the 
behavior  of  a  destroyed  AFRL-aircraft. 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-02 


Final  Report 
6  TRACE  Network  Connectivity 


6.4. 5. 1.2. 1.1.2  Bandwidth  as  a  function  of  the  number  of  entities 


S3:  PIS  -  Band width/#Enti ties 
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Fig.  6-43  S3-  DIS-  Used  Bandwidth/#Entities 

The  diagram  shows  the  required  bandwidth  for  the  Dasa  simulator’s  output  as  a  function  of  the  number  of  active 
entities.  The  narrow  line  represents  the  number  of  aircraft  (in  this  scenario  there  are  two  aircraft  each  at  both 
AFRL  and  Dasa).  In  scenario  3,  Dasa  controls  two  aircraft  and  their  missiles.  The  number  of  active  missiles  is 
added  to  the  number  of  aircraft  yielding  the  wide  line  which  represents 
missiles  +  aircraft  =  overall  number  of  represented  entities. 

At  about  t  =  250  seconds,  the  first  two  missiles  were  launched,  causing  a  higher  average  required  bandwidth  of 
about  50  kbit/sec.  This  requirement  remained  while  the  missiles  were  active.  Before  the  missiles  were  fired, 
before  t  =  250  seconds,  the  two  maneuverable  aircraft  required  a  bandwidth  of  between  20  and  40  kB  it/sec. 
During  the  next  two  launch  periods,  where  a  total  of  4  missiles  were  launched,  the  instantaneous  bandwidth 
requirements  were  inconsistent  with  variations  between  20  to  120  kBit/sec.  It  appears  that  all  the  missiles  were 
fired  at  the  same  aircraft  and  were  removed  with  the  AFRL-entity.  The  bandwidth  needed  for  the  remaining  two 
aircraft  returned  to  the  value  it  was  at  during  the  approach  phase. 

At  the  end,  one  additional  missile  was  launched  before  one  of  the  Dasa-entities  and  the  last  AFRL-entity  were 
killed. 

As  long  as  the  two  active  aircraft  are  agile,  they  need  a  datarate  of  up  to  40  kBit/sec.  If  they  are  not 
maneuvering  (flying  straight),  a  bandwidth  of  about  10  kBit/sec  is  needed  for  complete  coverage.  Additionally, 
one  missile  can  increase  the  required  bandwidth  to  60  kBit/sec.  Peaks  of  up  to  120kBit/sec  can  be  seen  when  4 
missiles  are  active. 
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6.4.5. 1.2.1. 2.1  Number  ofPDU’s  as  a  Function  of  the  Number  of  Entities 


Fig.  6-44  S3-  DIS-  #Entities/#PDU,s 


This  diagram  shows  the  number  of  each  type  of  PDU  transmitted  versus  the  number  and  type  of  active  entity.  It 
depicts  the  types  of  PDU’s  required  to  transmit  data  between  the  two  simulators  for  successful  regeneration  at 
the  opposite  site.  Again  the  number  of  active  missiles  is  added  to  the  number  of  active  aircraft.  In  this  scenario, 
Dasa  controls  two  aircraft  and  their  missiles. 

The  relatively  small  number  of  FTR-,  DET-  and  EAP-PDU’s  are  not  as  visible  as  they  were  in  the  simpler 
scenario  S2  as  a  scaling  result. 

While  the  aircraft  are  approaching  one  another,  there  are  some  ES-PDU’s  (Entity  State)  and  some  EMI-PDU’s 
(radar  emissions  and/or  IR  information). 

The  number  of  ES-PDU’s  increase  as  agile  maneuvers  are  being  performed  in  preparation  for  combat. 

The  first  missile  launch  causes  the  number  of  ES-PDU’s  to  increase  because  of  the  exchange  of  data  for  the  new 
high  speed  entities. 

The  number  of  EMI-PDU’s  decreases  in  relative  importance  to  the  number  of  ES-PDU’s  transmitted,  but  is 
nevertheless  higher  than  for  the  equivalent  number  of  scenario  S2. 


6-55 


Transatlantic  Research  into  Air  Combat  Engagements 
Doc.-No.:  Dasa-S-R- 1775-02 


Final  Report 
6  TRACE  Network  Connectivity 


6.4.5.  1.2. 1.2.2  Assignment  of  PDU-Types  over  one  Complete  Run 


Fig.  6-45  S3-  DIS  PDU-Percentage 

The  diagram  shows  that  the  ES-PDU  (Entity-State)  uses  the  largest  amount  of  bandwidth  followed  by  the  EMI- 
PDU  (Emission-PDU). 

For  each  missile  launched,  a  firing  information  (FIR-PDU)  and  detonation  information  (DET-PDU)  is  sent. 


6.4.5. 1.2.2  DIS-Lite-Protocol 


6.4.5 . 1 .2.2. 1  B  and  width 


6.4.5. 1.2.2. 1.1  Bandwidth  Usage 


S3:  DIS-Lite-  Used  Bandwidth 


60 

50 


0  100  200  300  400  500  600 


t/sec 

Wan_ln - WanOut 


Fig.  6-46  S3-  DIS-Lite-  Used  Bandwidth 

The  high  peak  in  bandwidth  on  the  “Wan-In“-line  at  t  =  200  and  310  seconds  is  a  result  of  the  dead  reckoning 
algorithm  transferring  a  large  amount  of  entity  state  data  in  response  to  a  tailspin  from  a  destroyed  AFRL-target. 
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Fig.  6-47  S3-  DIS-Lite-  Used  Bandwidth/#Entities 


To  determine  how  the  bandwidth  depends  on  entity  count,  the  amount  of  outgoing  information  (required 
bandwidth)  and  active  entity  count  are  plotted  versus  time  in  the  above  diagram. 

During  the  approach  phase,  the  two  Dasa-aircraft  need  a  relatively  noisy  10  to  20  kbit/sec  bandwidth.  At  the 
moment  a  missile  is  launched,  the  transfer  of  information  for  the  new  high  speed  entity  increases  the  required 
bandwidth  only  slightly  but  also  results  in  peaks  of  up  to  30  kbit/sec. 

At  the  moment  one  of  the  two  Dasa-aircraft  is  destroyed  (t  =  220  seconds),  the  datarate  drops  to  5  to  10  kbit/sec, 
which  is  still  slightly  higher  (especially  the  peaks)  than  the  datarate  for  one  target  in  scenario  S2.  There  are  no 
obvious  reasons  for  this  difference. 
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6.4.5. 1 .212.2  PDU-Statistics 


6.4.5. 1. 2.2.2. 1  Number  ofPDU's  as  a  Function  of  the  Number  of  Entities 


S3:  DIS-Lite  -  #Entities/#PDU's 


Fig.  6-48  S3-  DIS-Lite-  #Entities/#PDU,s 

A  high  number  of  KINE-PDU’s  (containing  the  high  dynamic  information  about  the  entity  state)  and  a  small 
number  of  EMI-PDU’s  (containing  the  emission  data)  transfer  the  state  of  the  approaching.  Launching  a  missile 
results  in  a  FIR-PDU,  some  QR-PDU’s,  and  a  large  number  of  KINE-PDU’s  being  sent.  These  PDU’s  indicate 
that  a  missile  has  been  fired,  relatively  static  information  about  the  entity,  and  the  dynamic  information  about  the 
entity,  respectively. 

6.4.5. 1. 2.2.2. 2  Assignment  of  PDU-Types  over  one  Complete  Run 


Fig.  6-49  S3-  DIS-Lite  PDU-Percentage 


Quantitatively,  the  KINE-PDU’s,  which  convey  dynamic  information  about  the  entity,  transfer  most  of  the  data 
to  be  exchanged.  These  PDU’s  are  supported  by  a  small  number  of  QR-PDU’s,  which  contain  the  rest  of  the 
entity  state  information,  the  relatively  static  information. 

The  emission  information  has  the  second  highest  count,  accounting  for  about  a  quarter  of  the  transferred  data 
packages. 
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For  each  launched  missile,  a  FIR-  and  a  DET-PDU’s  are  sent  to  inform  the  partner  about  the  new  or  removed 
entity. 

The  percentage  of  the  EMI-  and  KINE-PDU’s  are  equivalent  to  that  of  scenario  S2. 

6.4.5. 1.2.3  Dasa-Protocol 

6.4.5. 1.2.3. 1  Bandwidth 

6.4.5. 1.2. 3. 1.1  Bandwidth  Usage 


Fig.  6-50  S3-  Dasa-  Used  Bandwidth 

The  approach  and  combat  phases  are  not  obvious  when  using  the  Dasa-Protocol.  Overall,  a  scenario  with  the 
complexity  of  S3  needs  a  bandwidth  of  3  to  10  kbit/sec. 

The  very  high  bandwidth  value  at  the  beginning  of  the  run  on  the  input  line  is  due  to  initialization  problems. 
During  this  period  the  Dasa-simulation  was  not  active.  After  activation  the  Dasa-simulation,  the  input  value 
drops  to  a  reasonable  level.  After  about  t  =  50  seconds,  the  simulation  bandwidth  is  completely  stable. 

At  t  =  330  seconds,  a  AFRL-aircraft  goes  into  a  tailspin  after  being  hit  by  a  missile.  The  tailspin  causes  an 
increase  in  required  bandwidth  due  to  its  rapid  angular  changes.  In  effect,  it  doubles  the  bandwidth  required  and 
could  cause  problems  if  bandwidth  limitations  are  exceeded. 
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6.4.5. 1.2.3. 1.2  Bandwidth  as  a  function  of  the  number  of  entities 


S3:  DASA  -  Bandwidth/#Entitjes 
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Fig.  6-51  S3-  Dasa-  Used  Bandwidth/#Entities 


During  the  two  entity  approach  phase,  a  bandwidth  of  2  to  4  kbit/sec  is  needed. 

The  combat  phase  starts  with  the  launch  of  one  missile.  Later,  an  additional  two  missiles  are  launched.  The 
bandwidth  usage  slowly  increases  to  6  kbit/sec  to  handle  4  active  entities  (2  AC  and  2  MI). 

From  t  =  300  seconds  on,  after  a  Dasa-aircraft  launched  a  missile  and  before  it  was  killed,  the  number  of  active 
entities  drops  for  a  short  period  of  time  to  three  ( 1  AC  +  2  MI).  The  second  aircraft  then  launched  another 
missile.  So,  the  number  of  active  missiles  is  three  and  the  number  of  active  entities  is  4  (1  AC  +  2  MI). 
Comparing  the  2  AC  +  2  MI  case  to  the  1  AC  +  3  MI  case,  it  appears  that  an  aircraft  has  a  greater  influence  on 
bandwidth  than  a  missile. 
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6.4.5. 1. 2.3.2  PDU-Statistics 


6.4.5. 1.23.2.1  Number  ofPDU's  as  a  Function  of  the  Number  of  Entities 


Fig.  6-52  S3-  Dasa-  #Entities/#PDUfs 


At  the  moment  of  missile  activation  some  SDR-PDU’s  are  sent  to  handle  missile  information  exchange. 
Additionally,  the  increase  in  the  number  of  CDR-PDU’s  is  the  result  of  a  of  missile  avoidance  maneuver  by  at 
least  one  of  the  Dasa-aircraft.  The  eventual  decrease  in  the  number  of  CDR-PDU’s  is  a  result  of  the  destruction 
of  the  Dasa-aircraft. 

The  figure  also  shows  that  the  number  of  transmitted  RAD-  and  EAP-PDU’s  are  not  effected  by  the  agility  of  the 
entity.  It  also  shows  that  the  number  of  EAP-PDU’s  increase  with  the  number  of  active  entities. 

6.4.5. 1.2. 3.2.2  Assignment  of  PDU -Types  over  one  Complete  Run 
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Fig.  6-53  S3-  Dasa  PDU-Percentage 
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Fig.  6-53  shows  that  there  is  a  good  balance  in  the  number  of  PDU’s  sent.  When  these  percentages  are 
compared  to  those  of  scenario  S2  (which  was  a  much  simpler  scenario)  we  find  that  the  percentage  of  CDR- 
PDU’s  is  the  same,  the  percentage  of  RAD-PDU’s  has  doubled  as  a  result  of  a  higher  number  of  networked 
entities  and  the  percentages  of  EAP-  and  SDR- PDU’s  has  decreased  slightly. 


6.4.5. 1.2 A  Protocol  Comparison 


Fig.  6-54  S3  Protocol  Comparison 


The  diagram  above  compares  the  bandwidth  used  by  each  protocol  during  scenario  S3.  The  graphs  are  not 
directly  comparable  since  the  pilots  learned  from  each  run  and  changed  their  tactics  for  the  next  run.  However, 
the  plots  do  give  a  relative  idea  of  how  the  average  bandwidths  required  by  each  protocol  would  compare.  For 
the  analysis,  runs  with  similar  complexity  were  chosen,  especially  where  the  number  of  entities  were  concerned. 
The  runs  were  not  identical  but  the  scenario  and  its  complexity  were  the  same. 

To  get  a  better  idea  of  the  values,  a  10  per.  moving  average  was  calculated  for  each  recorded  line. 

Notice  that  the  DIS-ProtocoI  is  erratic  and  has  the  highest  bandwidth  requirements,  with  maximum  averaged 
rates  of  up  to  90  kbit/sec  and  a  measured  peak  bandwidth  requirements  out  to  120  kbit/sec. 

Notice  also,  that  the  DIS-Lite-protocol  is  also  somewhat  erratic  but  that  its  bandwidth  requirements,  up  to  25 
kbit/sec,  are  much  lower  than  that  of  DIS.  Additionally,  the  peak  values  have  been  reduced  greatly  as  compared 
to  DIS.  Also  notice  that  the  second  half  of  the  curve  represents  only  one  aircraft. 

The  Dasa-Protocol  shows  a  smoother  behavior  (less  variation  between  peaks  and  valleys)  and  a  lower  bandwidth 
requirement  at  less  than  10  kbit/sec  for  the  averaged  line.  Again,  the  averaged  line  shows  the  required 
bandwidth  for  the  Dasa-Protocol  to  be  one  third  that  of  the  DIS-Lite-protocol’ s. 

All  measurements  depict  a  low  datarate  during  the  approach  phases  and  a  steady  increase  in  required  bandwidth 
when  missiles  are  added  to  the  scenario  during  combat  phase. 
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6.4.5.1.3  Scenario  4:  4  v  2  +  2  Combat 

In  this  scenario,  two  hostile  forces  were  simulated.  Each  side  consisted  of  two  manned  and  2  digital  aircraft.  In 
this  scenario,  Dasa  fielded  2  manned  fighters  and  2  digital  bombers  and  AFRL  fielded  2  manned  and  2  digital 
fighters.  All  simulated  aircraft  are  equipped  with  a  complete  weapons  system. 

The  objective  of  this  scenario  is  to  prevent  the  hostile  force  from  entering  the  defender’s  territory  by  using 
MRMs,  SRMs  and/or  the  GUN. 

6.4.5.13.1  DIS-Protocol 

6.4.5. 1.3. 1.1  Bandwidth 


6.4.5. 1.3. 1.1.1  Bandwidth  Usage 


Fig.  6-55  S4-  DIS-  Used  Bandwidth 


In  the  middle  of  the  diagram  (t  =  500  seconds)  the  scenario  was  restarted,  so  actually  two  runs  of  scenario  S4 
will  be  discussed  within  this  and  the  following  paragraphs. 

Scenario  S4  required  a  bandwidth  of  up  to  200  kbit/sec  in  the  first  run  and  up  to  lOOkbit/sec  in  the  second.  This 
shows  the  influence  different  situations  have  on  bandwidth  requirements  for  a  more  complex  scenario.  This 
diagram  shows  how  different  tactics  can  effect  the  bandwidth  requirements.  As  can  be  seen,  the  second  run 
requires  about  half  the  bandwidth  of  the  first  run  even  thought  the  two  runs  used  the  same  scenario  (same 
number  and  type  of  entities  and  complexity).  Even  in  the  first  run  the  different  tactics  between  the  Dasa-  and  the 
AFRL-forces  has  the  same  influence  because  the  Dasa-simulation  needs  two  times  the  datarate  of  the  AFRL- 
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simulation.  This  is  not  caused  by  the  used  CGT  (Computer  Generated  Targets)  because  the  identical  scenario 
with  the  same  complexity  causes  in  the  second  run  just  the  half  of  bandwidth  need  for  the  Dasa-simulation. 

The  loss  of  the  input  line  at  t  =  200  seconds  seems  to  have  been  caused  by  a  failing  connection  line  or  router 
because  a  system  reset  would  have  resulted  in  a  new  approach  phase.  However,  the  input  line  (Wan_In)  in  the 
diagram  shows  no  real  break  in  its  behavior.  Normally  these  dropouts  can  be  covered  by  the  protocols. 


6.4.5. 1.3. 1.1.2  Bandwidth  as  a  function  of  the  number  of  entities 


S4:  D IS  -  Bandwidth/#Entities 


Fig.  6-56  S4-  DIS-  Used  Bandwidth/#Entities 


In  the  diagram,  you  can  see  the  required  bandwidth  for  the  output  of  the  Dasa  simulation  as  a  function  of  the 
number  of  active  entities. 

The  diagram  shows  that  the  high  datarate  from  the  Dasa-simulation  in  the  first  run  of  this  scenario  was  caused  by 
a  high  number  of  missiles  fired.  During  this  phase,  4  aircraft  and  5  missiles  are  controlled  by  the  Dasa- 
simulation  with  the  required  bandwidth  increasing  to  over  200  kbit/sec.  As  aircraft  are  destroyed  the  required 
bandwidth  slowly  decrease. 

The  second  run  shows  that  the  4  aircraft  need  about  100  kbit/sec  during  combat  engagements.  This  can  also 
been  seen  for  a  short  period  of  time  in  the  first  run.  The  datarate  is  much  lower  during  the  approach  phase  when 
there  are  no  combat  maneuvers  (as  at  the  beginning  of  run  2). 

At  the  end  of  the  first  run,  missing  scenario  management  functionality  resulted  in  new  CGT’s  being  started  and  a 
lot  of  missile  launches  by  the  Dasa-pilots.  Normally  these  procedure  effects  are  not  seen  in  the  diagrams  when 
there  is  only  one  run  visible. 
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6.4.5. 1.3. 1.2  PDU-Statistics 


6.4. 5. 1.3. 1.2.1  Number  of  PDU’s  as  a  Function  of  the  Number  of  Entities 


Fig.  6-57  S4-  DIS-  #Entities/#PDU's 


Figure  5-44  shows  that  the  ES-PDU  is  used  to  transfer  the  majority  of  the  simulation  data.  The  figure  also 
shows  that  the  number  of  ES-PDU’s  increases  dramatically  with  missiles  active. 


6.4.5. 1.3. 1.2.2  Assignment  ofPDU-Types  over  one  Complete  Run 


Fig.  6-58  S4-  DIS  PDU-Percentage 


Again,  it  is  obvious  that  nearly  all  the  information  for  this  scenario  is  transferred  by  the  ES-  and  the  EMI-PDU. 
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6.4.5. 1.3.2  DIS^Lite-Protocol 

6.4.5. 1. 3.2.1  Bandwidth 

6.4.5. 1.3.2. 1.1  Bandwidth  Usage 

S4:  DIS-Lite -  Used  Bandwidth 


Fig.  6-59  S4-  DIS-Lite-  Used  Bandwidth 

The  diagram  shows  the  bandwidth  usage  for  scenario  S4  using  the  DIS-Lite-protocol. 
Overall,  the  required  datarate  is  70  kbit/sec  with  no  peaks  visible  as  in  previous  scenarios. 

6.4.5. 1.3.2. 1.2  Bandwidth  as  a  function  of  the  number  of  entities 

S4:  DIS-Lite  -  Bandwidth/#Entities 
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Fig.  6-60  S4-  DIS-Lite-  Used  Bandwidth/#Entities 
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The  diagram  shows  that  during  the  approach  phase,  the  required  bandwidth  for  the  4  active  aircraft  was  about  50 
kbit/sec.  Additionally,  it  shows  that  in  the  combat  phase  with  the  addition  of  1  missile  the  required  bandwidth 
increases  to  70  kbit/sec.  At  the  end  of  this  run,  two  Dasa  aircraft  are  left  and  produce  a  datarate  of  about  15 
kbit/sec  which  agrees  with  the  datarate  seen  in  scenario  S3  for  the  same  number  of  entities.  Also  notice  the 
relatively  high  datarate  generated  by  four  entities  as  compared  to  that  generated  by  two  entities.  This  run  is 
comparable  to  the  DIS-protocol’s  second  run  because  of  similar  weapons  usage. 

6.4.5. 1. 3.2.2  PDU-Statistics 


6.4.5. 1. 3.2.2. 1  Number  ofPDU’s  as  a  Function  of  the  Number  of  Entities 


Fig.  6-61  S4-  DIS-Lite-  #Entities/#PDU’s 


Strangely,  the  missile  launched  at  t  =  80  seconds  does  not  result  in  a  sudden  increase  of  KINE-PDU’s. 

The  number  of  EMI-PDU’s  increases  at  t  =  50  seconds  from  10  to  20  PDU’s/sec  because  the  CGT  activated 
their  radar  system  as  late  as  possible  to  prevent  detection. 
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6.4.5. 13.2.2.2  Assignment  of  PDU-Types  over  one  Complete  Run 


Fig.  6-62  S4-  DIS-Lite  PDU-Percentage 

For  this  scenario,  the  DIS-Lite-protocol’s  KINE-  and  EMI-PDU’s  are  used  to  transfer  the  majority  of  the 
exchanged  information. 

6.4.5.13.3  Dasa-Protocol 

6.4.5. 1. 3.3.1  Bandwidth 

6.4.5.133.1.1  Bandwidth  Usage 


Fig.  6-63  S4-  Dasa-  Used  Bandwidth 
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For  this  scenario,  the  datarate  during  the  approach  phase  for  the  four  AFRL  and  DAS  A  aircraft  is  about  10 
kbit/sec  and  increases  to  about  30  kbit/sec  during  the  combat  phase  which  ends  at  about  t  =  300  seconds.  After  t 
=  300  seconds  the  curve  represents  a  dogfight  between  the  aircraft  on  the  AFRL  and  Dasa-sides. 

Again,  the  tailspin  effect  of  a  destroyed  AFRL  aircraft  is  visible  about  t  =  700  seconds  on  the  input  line. 


6.4.5. 1.3.3. 1.2  Bandwidth  as  a  function  of  the  number  of  entities 


Fig.  6-64  S4- Dasa- Used  Bandwidth/#Entities 


In  additional  to  the  four  Dasa  controlled  aircraft,  up  to  seven  missiles  get  activated  at  the  same  time  during 
combat  phase.  The  number  of  entities  and  needed  datarate  drops  as  two  aircraft  are  destroyed  and  missiles  bum 
out  or  detonate. 
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6.4.5. 1. 3.3.2  PDU-Statistics 


6.4.5.1.33.2.1  Number  ofPDU’s  as  a  Function  of  the  Number  of  Entities 


Fig.  6-65  S4-  Dasa-  #Entities/#PDU,s 

To  cover  the  necessary  information  exchange  for  EW,  the  number  of  RAD-PDU’s  stays  at  a  relatively  high  level 
while  all  8  aircraft  are  active.  As  aircraft  are  removed  from  the  scenario  due  to  missile  hits,  the  number  of  RAD- 
PDU’s  drops  dramatically. 

From  the  figure,  you  can  see  the  effect  that  launching  missiles  has  on  the  number  of  SDR-PDU’s.  Additionally, 
the  Dasa  aircraft’s  missile  avoidance  maneuvers  causes  the  number  of  CDR-PDU’s  to  increase  dramatically. 
Also,  the  increase  in  the  number  of  entities  cause  a  slight  increase  in  the  number  of  EAP-PDU’s. 


6.4.5.1.33.2.2  Assignment  of  PDU -Types  over  one  Complete  Run 


Fig.  6-66  S4-  Dasa  PDU-Percentage 
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Again,  the  CDR-PDU  carries  about  a  third  of  the  exchanged  information.  The  percentage  of  RAD-PDU’s  used  is 
higher  than  in  the  earlier  scenarios  due  to  the  increased  number  of  aircraft.  Also,  the  percentage  of  EAP-PDU’s 
is  about  the  same  as  in  scenarios  S2  and  S3,  since  it  is  a  function  of  the  number  of  active  entities 

The  complete  information  exchange  is  balanced  quite  well  using  these  four  PDU-types. 

6.4.5. 1.3.4  Protocol  Comparison 


S4:  Comparison  DIS-/DASA-/DIS-Lite-Protocol 


t/sec 


. . W*S_OUt  <DASA)  Ottt  (DIS) 

wan_Out  (Dis-Lit«)  10  per  moving  average  (Wan_Out  (DIS)) 

-  10  per  moving  average  (Wan_Oui  (DASA))  -  10  per  moving  average  (Wan.Out  (DIS-Lite)) 


Fig.  6-67  S4  Protocol  Comparison 

The  diagram  above  compares  the  bandwidth  used  by  each  protocol  during  scenario  S4.  The  graphs  are  not 
directly  comparable  since  the  pilots  learned  from  each  run  and  changed  their  tactics  for  the  next  run.  However, 
the  plots  do  give  a  relative  idea  of  how  the  average  bandwidths  required  by  each  protocol  would  compare.  For 
the  analysis,  runs  with  similar  complexity  were  chosen,  especially  where  the  number  of  entities  were  concerned. 
The  runs  were  not  identical  but  the  scenario  and  its  complexity  were  the  same.  The  curve  for  the  DIS-Protocol 
actually  represents  two  runs  of  the  same  scenario  but  with  different  situations  are  previously  discussed. 

To  get  a  better  idea  of  the  values,  a  10  per.  moving  average  was  calculated  for  each  recorded  line. 

Notice  that  there  was  a  need  for  a  200  kbit/sec  bandwidth  with  the  ISDN-line  providing  only  128  kbit  overall. 
Nevertheless,  it  was  still  possible  to  complete  the  training  session,  since  there  were  only  a  few  dropouts  on  the 
AFRL-site. 

Notice  again  that  the  DIS-Protocol  is  erratic  and  has  the  highest  bandwidth  requirements.  Notice  also,  that  the 
DIS-Lite-protocol  is  also  somewhat  erratic  but  that  its  bandwidth  requirements,  up  to  70  kbit/sec,  are  lower  than 
that  of  DIS.  The  tactical  situation  and  the  pilot’s  actions  for  the  DIS-Lite  run  are  similar  to  the  second  run  of  the 
DIS-curve.  Comparing  the  DIS-  and  DIS-Lite-protocols  for  this  type  of  run  shows  that  the  advantage  in  using 
DIS-Lite  over  DIS  is  not  quite  as  high  as  in  previous  runs.  However,  DIS-Lite  still  uses  only  2/3r  of  the  DIS 
datarate  . 


Again  the  bandwidth  needed  by  the  Dasa-Protocol  is  still  very  small  even  though  this  run  has  highest  number  of 
active  entities  (4  aircraft  and  7  missiles). 
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average  bandwidth  need 
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<200  kbit/sec 

<220  kbit/sec 

(lOOkbit/sec) 

DIS-Lite 

<65  kbit/sec 

<70  kbit/sec 

Dasa 

<20  kbit/sec 

<30  kbit/sec 

6.4.5.1.4  Scenario  5:  2  +  2  v  4  Joint  Combat 

In  this  scenario  two  hostile  forces  were  simulated  but  this  time  both  the  AFRL  and  the  Dasa  cockpits  are 
performing  a  joint  mission  against  a  hostile  force  made  up  of  4  CGT’s  (Computer  Generated  Targets).  All 
CGT’s  are  controlled  by  the  Dasa  simulation  and  have  a  different  force  ID  than  the  Dasa  manned  cockpits  which 
has  the  same  force  ID  as  the  AFRL  cockpits.  A  communication  link  between  the  AFRL  and  Dasa  cockpits  was 
established  via  a  separate  telephone  line.  All  aircraft  were  equipped  with  a  complete  weapon  system. 

In  this  scenario,  Dasa  controls  2  manned  and  4  digital  aircraft  and  their  missiles.  AFRL  controls  two  aircraft 
and  their  missiles.  Because  of  this,  the  output  line  in  the  diagrams  shows  a  larger  datarate  than  the  input  line. 
This  scenario  extends  the  requirements  of  the  TRACE  program  if  you  survey  the  Dasa  output  line  which  will  be 
discussed  in  the  following  chapter. 

The  objective  of  this  scenario  is  to  prevent  the  hostile  force  from  entering  the  defender’s  territory  by  using 
MRMs,  SRMs  and/or  the  GUN. 

Even  though  the  datarate  using  the  DIS-Lite-protocol  was  less  than  for  the  DIS-Protocol  in  previous  scenarios,  it 
was  not  possible  to  setup  and  run  with  the  DIS-Lite  protocol  in  this  scenario.  The  problem  could  not  be 
resolved  and  was  not  a  subject  of  the  TRACE  program.  It  seems  that  dropouts  due  to  bandwidth  limitations, 
even  very  small  ones,  could  not  be  sufficiently  recovered  by  the  DIS-Lite  protocol  and  even  leads  to  problems  in 
the  simulation  computers.  Further  analysis  could  help  to  analyze  if  there  is  a  problem  in  the  object  libraries  or 
the  implementation. 
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6  A.  5. 1  A.  1  DIS-Protocol 
6.4.5. 1 .4.1.1  Bandwidth 


6A.5AAA.1A  Bandwidth  Usage 


Fig.  6-68  S 5-  DIS-  Used  Bandwidth 


The  WanOut-line  in  the  diagram  shows  that  the  required  bandwidth  for  the  six  Dasa  aircraft  reaches  220  kbit/sec 
for  this  scenario. 
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6.4.5.  1.4. 1.1.2  Bandwidth  as  a  function  of  the  number  of  entities 


Fig.  6-69  S5-  DIS-  Used  Bandwidth/#Entities 


The  diagram  shows  the  required  bandwidth  for  the  output  from  the  Dasa  simulation  as  a  function  of  the  number 
of  active  entities.  It  shows  a  strong  correlation  between  the  number  of  entities  and  the  datarate.  In  this  instance, 
firing  3  missiles  tripled  the  datarate.  As  the  missiles  burn  out  the  datarate  slowly  decreases. 

From  t  =  250  seconds  on,  four  of  the  six  Dasa  controlled  aircraft  are  destroyed. 

At  t  =  340  seconds,  the  CGT’s  at  Dasa  were  restarted  and  the  number  of  active  aircraft  at  Dasa  increased  to  5  (1 
cockpit  plus  4  CGT’s).  At  about  the  same  time,  a  lot  of  missiles  were  fired. 

At  the  end,  another  group  of  missiles  were  launched  just  prior  to  a  system  reset. 
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6.4.5. 1.4. 1.2  PDU-Statistics 

6.4.5.1.4.12.1  Number  of  PDU’s  as  a  Function  of  the  Number  of  Entities 

SS:  DIS  -  #Entities/#PDU's 


t/sec 


ESgTiAC  e— M - DET - EAR  ES - FIR - EMI 


Fig.  6-70  S5-  DIS-  #Entities/#PDU's 

The  high  number  of  ES-PDU’s  at  the  beginning  of  the  plot  are  caused  by  maneuvers  for  formation  bonding 
before  the  aircraft  begin  their  approach  phase.  The  figure  also  shows  that  launching  missiles  results  in  increased 
numbers  of  ES-PDU’s  and  EMI-PDU’s. 
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6 A. 5. 1.4. 1.2.2  Assignment  of  PDU -Types  over  one  Complete  Run 


Fig.  6-71  S5-  DIS  PDU-Percentage 

As  in  previous  scenarios,  information  exchange  for  this  scenario  is  performed  primarily  by  ES-  and  EMI-PDU’s 
6.4.5. 1.4.2  Dasa-Protocol 
6.4.5. 1 .4.2. 1  Bandwidth 


6.4.5. 1.4.2. 1.1  Bandwidth  Usage 


Fig.  6-72  S5-  Dasa-  Used  Bandwidth 
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This  diagram  shows  the  bandwidth  required  for  scenario  S5  when  using  the  Dasa  protocol.  As  long  as  the 
entities  are  not  maneuvering  the  datarate  stays  below  10  kbit/sec.  During  the  combat  phase,  the  Dasa 
simulation’s  required  bandwidth  increases  to  25  kbit/sec  with  a  peak  of  30  kbit/sec. 

The  high  datarate  on  the  Wan  Jn  line  is  probably  caused  by  a  tailspin  from  a  AFRL  aircraft. 

6.4.5. 1.4.2. 1.2  Bandwidth  as  a  function  of  the  number  of  entities 


S5:  DASA  -  Bandwidth/#Entities 
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Fig.  6-73  S5-  Dasa-  Used  Bandwidth/#Entities 

During  this  scenario  the  Dasa  simulation  controlled  up  to  1 1  entities  (6  aircraft  5  missiles  after  t  =  160  seconds 
and  4  aircraft  and  7  missiles  after  t  =  320  seconds).  The  curve  for  used  bandwidth  follows  the  line  for  the 
number  of  controlled  entities  quite  closely. 
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6.4.5. 1. 4.2.2  PDU-Statistics 

6.4.5. 1. 4.2.2. 1  Number  ofPDU’s  as  a  Function  of  the  Number  of  Entities 


Fig.  6-74  S5-  Dasa-  #Entities/#PDUs 

This  diagram  shows  the  types  of  PDU  affected  by  launching  a  large  number  of  missiles. 

The  Dasa  simulation  uses  CDR-  and  EAP-PDU’s  to  update  information  about  the  state  of  its  six  aircraft. 
Furthermore,  the  number  of  RAD-PDU’s  transmitted  is  still  small.  This  is  because  radar  information  between 
local  simulators  is  only  visible  locally.  Since  Dasa  controls  six  aircraft  locally,  only  data  effecting  the  AFRL 
entities  is  transmitted. 

As  in  previous  scenarios,  SDR-PDU’s  are  used  to  exchange  information  about  the  Dasa  controlled  missiles. 
Also,  due  to  the  increase  in  the  number  of  entities,  the  number  of  EAP-  and  RAD-PDU’s  increase. 

The  high  number  of  CDR- PDU’ s  after  t  =  200  seconds  are  the  result  of  an  aircraft  maneuvering  to  avoid  a 
missile.  The  aircraft  was  subsequently  hit  by  the  missile  as  can  be  seen  by  the  number  of  missiles  and  the 
number  of  aircraft  decreasing  at  the  same  time 
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6.4. 5.1 .4.2. 2.2  Assignment  of  PDU-Types  over  one  Complete  Run 


Fig.  6-75  S5-  Dasa  PDU-Percentage 

Because  the  dispersion  of  active  aircraft  was  not  balanced,  the  percentage  of  RAD-PDU’s  was  not  as  high  as  it 
was  in  previous  scenarios.  In  other  words,  most  of  the  emission  information  was  exchanged  between  locally 
simulated  entities  and  not  visible  at  the  output  line.  Thus,  over  50%  of  the  data  was  exchanged  via  CDR-PDU’s 
between  the  Dasa-  and  the  AFRL  simulations. 

6.4.5. 1.4. 3  Protocol  Comparison 


Fig.  6-76  S5  Protocol  Comparison 
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The  diagram  above  compares  the  bandwidth  used  by  each  protocol  during  scenario  S5.  The  graphs  are  not 
directly  comparable  since  the  pilots  learned  from  each  run  and  changed  their  tactics  for  the  next  run.  However, 
the  plots  do  give  a  relative  idea  of  how  the  average  bandwidths  required  by  each  protocol  would  compare.  For 
the  analysis,  runs  with  similar  complexity  were  chosen,  especially  where  the  number  of  entities  were  concerned. 
The  runs  were  not  identical  but  the  scenario  and  its  complexity  were  the  same. 

To  get  a  better  idea  of  the  values,  a  10  per.  moving  average  was  calculated  for  each  recorded  line. 

While  the  ISDN-line  only  provided  a  bandwidth  of  128  kbit/sec,  the  required  bandwidth  was  more  that  220 
kbit/sec  for  the  DIS-Protocol.  This  caused  data  loss  at  the  receiving  site.  The  algorithms  used  by  the  DIS- 
Protocol  were  unable  to  recover  from  this  data  loss  which  effected  the  appearance  of  the  distant  entities. 

The  significant  difference  of  the  bandwidths  needed  by  the  two  protocols  is  clearly  visible.  For  the  DIS- 
Protocol,  the  tactical  situation  and  resulting  use  of  weapons  causes  a  high,  unpredictable  datarate  while  the  Dasa 
protocol  remains  at  a  reasonable  level. 
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6.4.5.1.5  Added  Scenario:  2  +  2  v  6  Joint  Combat 

In  this  scenario  two  hostile  forces  were  simulated  but,  as  in  scenario  S5,  both  the  AFRL  and  the  Dasa  manned 
cockpits  are  performing  a  joint  mission  against  a  hostile  force  made  up  of  6  CGT’s  (Computer  Generated 
Targets).  All  CGT’s  are  controlled  by  the  Dasa  simulation  and  have  a  different  force  ID  than  the  Dasa  manned 
cockpits  which  has  the  same  force  ID  as  the  AFRL  cockpits.  A  communication  link  between  the  AFRL  and 
Dasa  cockpits  was  established  via  a  separate  telephone  line.  All  aircraft  were  equipped  with  a  complete  weapon 
system. 

In  this  scenario,  Dasa  controls  2  manned  and  6  digital  aircraft  and  their  missiles.  AFRL  controls  two  aircraft 
and  their  missiles.  Because  of  this,  the  output  line  in  the  diagrams  shows  a  larger  datarate  than  the  input  line. 

For  that  this  scenario  extends  the  requirements  of  the  TRACE  program  if  you  survey  the  Dasa  output  line  which 
will  be  discussed  in  the  following  section. 

The  objective  is  to  prevent  the  hostile  force  from  entering  the  defenders  territory  by  using  MRMs,  SRMs  and/or 
the  GUN. 

This  scenario  was  generated  as  a  result  of  a  request  by  the  pilots  for  a  joint  mission  against  a  more  powerful 
force  of  CGT’s  in  hopes  of  increasing  the  effect  of  training  on  such  an  international  mission.  Unfortunately,  it 
was  not  possible  to  setup  and  run  this  scenario  using  the  DIS  protocol  because  of  the  128  kbit/sec  bandwidth 
limitation  imposed  by  the  two  ISDN-B-channels. 
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6.4. 5. 1.5. 1  Bandwidth 

6.4.5. 1 .5. 1 . 1  Bandwidth  Usage 

S5+:  DASA-  Used  Bandwidth 


Fig.  6-77  S5+-  Dasa-  Used  Bandwidth 

In  this  scenario,  Dasa  controls  2  manned  and  6  digital  aircraft  and  their  associated  missiles.  AFRL  controls  two 
aircraft  and  their  missiles.  Because  of  this,  the  output  line  in  the  diagrams  shows  a  larger  datarate  than  the  input 
line.  Of  interest  here  is  that  the  datarate  for  the  8  Dasa  controlled  aircraft  (without  any  launched  missiles)  is  just 
twice  the  datarate  from  the  2  AFRL  controlled  aircraft  (even  with  more  emission  information  sent  from  AFRL  to 
Dasa). 

The  WanOut’s  decreased  (after  t  =  500  seconds)  datarate  is  the  result  of  a  reduction  in  the  number  of  aircraft. 
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6.4.5. 1 .5 . 1 .2  Bandwidth  as  a  function  of  the  number  of  entities 
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Fig.  6-78  S5+-  Dasa-  Used  Bandwidth  /#Entities 


The  scenario  starts  with  eight  local  aircraft  performing  the  approach  phase.  The  used  datarate  increases  from  10 
to  25  kbit/sec  as  the  combat  phase  begins.  At  t  =  500  seconds,  most  of  the  Dasa  controlled  aircraft  are  destroyed 
and  the  datarate  drops  to  the  value  corresponding  to  that  of  scenario  S4  (S4  had  4  active  aircraft). 

Up  to  12  entities  were  controlled  by  the  Dasa  simulation  at  the  same  time  and  provided  for  the  interconnected 
scenario. 
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6.4.5. 1.5. 2  PDU -Statistics 


6.4.5. 1 .5.2. 1  Number  of  PDU’s  as  a  Function  of  the  Number  of  Entities 


Fig.  6-79  S5+-  Dasa-  #Entities/#PDU's 


The  number  of  RAD-PDU’s  is  still  small  as  in  scenarios  S2  to  S4  because  most  of  the  involved  entities  are 
simulated  locally  and  the  emission  information  only  has  to  be  provided  for  the  2  distant  AFRL  controlled 
aircraft  and  their  missiles. 

The  diagram  shows  the  effect  of  missile  launches  on  the  amount  of  SDR-PDU’s  and  the  effect  of  agile 
maneuvering  on  the  number  of  CDR-PDU  s. 

6.4.5. 1.5.2.2  Assignment  of  PDU-Types  over  one  Complete  Run 


Fig.  6-80  S5+-  Dasa  PDU-Percentage 


As  in  scenario  S5,  the  unbalanced  dispersion  of  involved  entities  results  in  a  high  percentage  of  CDR-PDU’ s. 
The  percentages  of  the  types  of  PDUs  used  is  in  accordance  with  the  analysis  of  the  scenario  S5,  even  thought 
this  scenario  is  more  complex. 
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6.4.5.1.6  Added  Scenario:  Ivlvlvl  Combat 

This  scenario  was  generated  on  request  of  the  pilots  as  a  training  scenario  for  high  agility  maneuvering.  Four 
manned  cockpits  (2  at  AFRL  and  2  at  Dasa),  all  hostile,  are  placed  in  opposite  direction  and  same  distance  to  an 
imaginary  central  point.  Each  pilot  tries  to  out  maneuver  and  kill  a  hostile  aircraft  with  either  a  SRM  or  GUN. 
A  possible  kill  will  be  overwritten  by  simulation  software,  but  the  aircraft  must  go  out  of  range  and  re-enters 
after  a  short  period  of  time. 

For  such  a  scenario,  the  measurements  represent  the  influence  of  high  agility  aircraft  maneuvers  on  the  required 
bandwidth. 

This  scenario  was  only  performed  using  the  Dasa  protocol. 

6.4.5. 1.6.1  Bandwidth 

6.4.5. 1 .6. 1 . 1  Bandwidth  Usage 


S6:  DASA -  Used  Bandwidth 
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Fig.  6-81  S6-  Dasa-  Used  Bandwidth 

Due  to  many  reasons,  the  AFRL  simulation  was  reinitialized  at  t  =  70  seconds  and  was  removed  from  the 
scenario  at  t  =  280  seconds. 

The  curves  represent  the  datarate  for  each  of  the  two  controlled  aircraft  and  their  launched  missiles.  The  datarate 
is  noisier  than  in  previous  scenarios  when  using  the  Dasa  protocol. 
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6.4.5. 1.6. 1.2  Bandwidth  as  a  function  of  the  number  of  entities 


Fig.  6-82  S 6-  Dasa-  Used  Bandwidth/#Entities 


Because  of  the  simulation’s  overwrite  function,  there  are  always  2  aircraft  active  even  if  they  have  been 
destroyed. 

A  bandwidth  of  4  kbit/sec  with  peaks  up  to  10  kbit/sec  is  needed  for  this  scenario. 
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6. 4. 5 .1. 6. 2  PD  U -Statistics 


6.4.5. 1 .6.2. 1  Number  of  PDU’s  as  a  Function  of  the  Number  of  Entities 


Fig,  6-83  S6-  Dasa-  #Entities/#PDU's 

The  peaks  in  the  curve  represent  the  number  of  CDR- PDU’s  which  can  be  in  comparison  with  datarate  diagrams 
before  correlated  with  peaks  of  the  used  datarate.  Additionally,  the  RAD-PDU  curve  shows  that  the  radar 
systems  were  switched  off  during  the  first  seconds.  As  the  AFRL  simulation  was  taken  out  of  the  scenario  at  t  = 
280  seconds,  this  results  in  the  total  absence  of  RAD-PDUs  since  emission  data  not  longer  needs  to  be  sent  to 
AFRL. 

6.4.5. 1 .6.2.2  Assignment  of  PDU-Types  over  one  Complete  Run 


S6:  DASA  -  PDU-A  veraae 
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Fig.  6-84  S6-  Dasa  PDU-Percentage 


In  this  scenario,  since  only  SRMs  were  allowed  to  be  fired,  only  a  few  missiles  were  launched.  This  results  in  a 
small  amount  of  missile  depend  information  which  was  exchanged  via  SDR-PDU’s. 
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The  percentage  of  transmitted  RAD-PDU’s  in  this  run  is  relatively  low  because  the  AFRL  simulation  was  taken 
out  of  the  scenario  rather  early. 

6.4.5.2  Scenario  Comparison 

A  protocol’s  effectiveness  is  measured  by  how  accurately  a  receiving  site  can  regenerate  the  transmitting  sites 
values  and  by  how  demanding  it  is  on  system  resources.  While  objective  measurements  can  be  made  using 
precise  positioning  which  yields  theoretical  results,  the  subjective  impression  of  the  pilots  as  the  end  user  is 
more  relevant  to  system  configuration. 

During  the  tests,  the  pilots  could  not  tell  which  protocol  was  being  used  even  if  switched  during  a  given 
scenario.  However,  if  bandwidth  limitations  imposed  by  the  ISDN  connection  were  exceeded  loss  of  data  would 
result  and  thus  the  loss  of  the  ability  to  regenerate  networked  aircraft.  When  this  occurred,  the  training  sessions 
became  insufficient,  ineffective  and  inconvenient.  The  protocol  leading  to  this  situation  would  not  be  used  for 
further  more  complex  scenarios. 

The  Fig.  6-85  shows  the  bandwidth  required  by  all  the  protocols  used  for  all  the  scenarios.  The  data  rate  is 
drawn  in  increments  of  50  kbit/sec,  approximate  usable  bandwidth  of  one  ISDN-B-channel.  The  maximum 
usable  bandwidth  defined  by  the  TRACE  program  was  the  usable  rate  of  2  ISDN-B-channels,  about  110 
kbit/sec. 

If  the  available  bandwidth  is  exceeded,  the  data  to  be  exchanged  will  either  be  sent  with  some  increased  latency 
or  be  discarded.  It  is  up  to  the  network  interface  computers  (NIC)  to  handle  these  situations  without  loss  or 
damage  to  data. 

Scenarios  S2  to  S5+  increase  in  complexity  by  increasing  the  number  of  aircraft  involved.  All  protocols  were 
suitable  for  scenarios  S2  to  S4  even  when  the  peak  bandwidth  value  of  the  DIS-Protocol  exceeded  the  ISDN 
limitation.  Normally,  data  can  be  correctly  transferred  but  with  some  increase  in  latency  which  can  cause  a 
positioning  error  higher  than  the  preset  one.  Such  errors  would  only  be  seen  in  the  visual  system  if  the  aircraft 
are  flying  relatively  close,  in  formation  or  some  kind  of  dogfight. 

In  scenario  S4,  the  data  rate  produced  using  the  DIS-Protocol  could  not  be  covered  by  the  bandwidth  of  the  2 
ISDN-B-channels.  While  the  training  session  was  completed  by  the  pilots,  the  preset  thresholds  were  exceeded 
as  expected.  If  the  active  entity’s  position  is  not  precise  enough,  the  correct  use  of  weapons  cannot  be 
guaranteed.  This  can  result  in  such  effects  as  multiple  targets  in  the  radar  systems,  problems  with  radar 
detection,  or  errors  in  missile  hit  calculations. 

According  to  the  scenario  S4  discussion,  scenario  S5  should  cause  the  DIS-Protocol  to  exceed  the  bandwidth 
limitations,  but  the  training  sessions  could  be  completed  by  the  pilots  again.  Of  interest  is  that  the  DIS-Protocol 
has  about  the  same  data  rate  as  in  the  previous  scenario  even  though  there  are  more  simultaneously  active 
entities.  Because  it  was  not  an  objective  of  the  TRACE  program  to  study  the  behavior  of  the  protocols  if  the 
bandwidth  limitations  are  exceeded,  a  closer  look  could  be  done  in  analyzing  the  reason  of  the  smaller 
bandwidth  need  of  the  DIS-Protocol  during  scenario  S5.  An  explanation  could  be  the  unbalanced  dispersion  of 
active  entities  over  the  network  resulting  in  less  EMI-PDU’s  to  be  sent  for  radar  and  IR-information  exchange. 
Since  DIS-Lite  exceeded  the  bandwidth  limitation  during  setup  it  could  not  recover  from  the  data  loss,  therefore, 
it  could  not  be  used  for  scenario  S5.  The  incoming  data  also  caused  problems  in  the  simulation  computers. 

In  all  the  scenarios,  the  datarate  produced  by  the  Dasa  protocol  could  have  been  handled  by  just  one  of  the  two 
ISDN-B-channels.  Scenario  S6  represents  the  data  rate  of  just  two  very  agile  aircraft  with  a  small  number  of 
missiles.  Of  interest  is  the  higher  average  and  peak  data  rate  when  compared  to  scenario  S2  which  also 
represents  the  data  rate  for  two  less  agile  aircraft. 

For  all  the  protocols,  the  difference  between  the  peak  and  average  data  rates  does  not  increase  with  the  more 
complex  scenarios  even  though  the  scenarios  cause  high  average  data  rates. 
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Fig.  6-85  Used  Bandwidth 


Fig.  6-86  Used  Bandwidth  per  Entity 


The  initialized  scenario  defines  the  complexity  by  giving  the  training  session  more  aircraft  and  therefore  more 
possibilities  to  act.  The  complexity  for  the  networking  technology  especially  for  the  protocols  are  the  overall 
number  of  active  participants.  The  influences  of  aircraft  and  missiles  as  well  as  their  dispersion  over  the 
network  is  quite  different.  The  Fig.  6-86  compares  the  used  protocols  in  their  datarate  produced  by  one  active, 
local  controlled  entity  (aircraft  or  missile)  in  accordance  to  the  scenarios. 

The  datarate  per  entity  produced  by  the  protocols  raises  with  the  complexity  of  the  scenario.  While  the  value  for 
the  DIS-Lite  protocol  increases  its  gradient,  the  DIS  value  raise  quite  constantly.  The  DIS  protocol  value  for  S5 
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may  be  a  result  of  the  unbalanced  dispersion  of  aircraft  with  the  effect  of  reducing  EMI-PDU  distribution  over 
WAN. 

In  contrast  the  Dasa  protocol  produces  a  lower  datarate  per  active  entity  because  of  the  relative  small 
information  package  (SDR-PDU)  for  missile  information  exchange. 
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3D 

Three  Dimensional 

2D 

Two  Dimensional 

A/A 

Air-to-Air 

ADI 

Attitude  Direction  Indicator 

ADS  - 

Advanced  Distributed  Simulation 

AFRL  - 

Air  Force  Research  Laboratory 

AFRL/VA 

Air  Force  Research  Laboratory  Air  Vehicles  Directorate 

AFRL/VACD 

Air  Force  Research  Laboratory  Air  Vehicle  Simulation  Branch 

AMG  - 

Architecture  Management  Group 

AMRAAM 

Advanced  Medium  Range  Air-to-Air  Missile 

AMS 

and  Automated  Maneuvering  Attack  System 

AOA  - 

Angle  of  Attack 

AOI 

Area  of  Interest 

API  - 

Application  Programming  Interface 

ASC  - 

Aeronautical  Systems  Center 

BVR  - 

Beyond  Visual  Range 

C4I 

Command,  Control,  Communications,  Computers  and  Intelligence 

CGF 

Computer  Generated  Force 

CGI 

computer  generated  image 

CGT 

Computer  Generated  Target 

CPU 

Central  Processing  Unit 

CSMA/CD 

Carrier  Sense  Multiple  Access/Collision  Detection 

DARPA  - 

Defense  Advanced  Research  Projects  Agency 

DASA 

Daimler-Benz  Aerospace  AG 

DD/PC  - 

Data  Dictionary/Protocol  Catalog 

DDR&E 

Director,  Defense  Research  &  Engineering 

DIS 

Distributed  Interactive  Simulation 

DMSO  - 

Defense  Modeling  and  Simulation  Office 

DoD  - 

Department  of  Defense 

DOF 

Dimensions  of  Freedom 

DSI 

Defense  Simulation  Internet 

ECM  - 

Electronic  Counter  Measures 

EFOV  - 

Expanded  Field  of  View 

ESIG 

Evans  &  Sutherland  image  generators 

EVDAS - 

Electronic  Visual  Display  Attitude  Sensor 

FFN 

Friend,  Foe,  Neutral 

FOV  - 

Field  of  View 

FOM  - 

Federation  Object  Model 

FLOT 

forward  line  of  own  troops 

GLOC  - 

G-Induced  Loss  of  Consciousness 

GPS  - 

Global  Positioning  System 
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GUI 

Graphical  User  Interface 

HDD  - 

Heads  Down  Display 

HOTAS - 

Hands  On  Throttle  And  Stick 

HLA  - 

High  Level  Architecture 

HUD  - 

Head-Up  Display 

Hz 

Hertz 

ICAAS 

Integrated  Control  and  Avionics  for  Air  Superiority 

IFF 

Identification  Friend,  Foe 

IEEE  - 

Institute  of  Electrical  and  Electronics  Engineers 

IFF 

Identification  Friend/Foe 

IG 

Image  Generator 

I/O 

Input/Output 

IR 

Infrared 

IP 

Internet  Protocol 

iRMX  - 

Intel  RMX 

I/ITSEC- 

Interservice/Industry  Training  Systems  and  Education  Conference 

Km 

Kilometers 

LAN  - 

Local  Area  Network 

LCD  - 

Liquid  Crystal  Display 

LOS 

Line  of  Sight 

M&S  - 

Modeling  &  Simulation 

MCS  - 

Manned  Combat  Station 

MLE  - 

Missile  Launch  Envelope 

MOU 

Memorandum  of  Understanding 

MPD  - 

Multipurpose  Display 

MRM  - 

Medium  Range  Missile 

NED  - 

North-East-Down 

NETS  - 

Network  Evaluation  for  Training  and  Simulation 

NIC 

Network  Interface  Computer 

NIU 

Network  Interface  Unit 

nm  or  NM 

Nautical  Miles 

NZ 

Normal  Acceleration 

OMT  - 

Object  Model  Template 

OTW  - 

Out  The  Window 

PDT  - 

Primary  Designated  Target 

PDU  - 

Protocol  Data  Unit 

Pk 

Probability  of  Kill 

PLA  - 

Power  Lever  Angle 

PRF 

Pulse  Repetition  Frequency 

PIT 

Press-To-Talk 

PVI 

Pilot  Vehicle  Interface 

RCS 

Radar  Cross  Section 

RMAX1- 

Maximum  Effective  Missile  Launch  Range  (3G  endgame  maneuver) 

RMAX2- 

Maximum  Effective  Missile  Launch  Range  (6G  maneuver  at  10  Km) 
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RMIN  - 

Minimum  Missile  Launch  Range 

RMS  - 

Reflective  Memory  System 

RTI 

Run  Time  Interface 

RWR  - 

Radar  Warning  Receiver 

SA 

Situation  Awareness 

SAM  - 

Surface-to-air-Missile 

SBIR  - 

Small  Business  Innovative  Research 

see 

Simulation  Control  Console 

SD 

Situation  Display 

SG 

Silicon  Graphics 

SNAP  - 

Simulation  Network  Analysis  Project 

SOM  - 

Simulation  Object  Model 

SOW 

Statement  of  Work 

SPO  - 

Systems  Program  Office 

SRM  - 

Short  Range  Missile 

STGVIP- 

Special  Task  Group  for  Vision  Implementation  Plan 

STOW  - 

Synthetic  Theater  of  War 

STOW-E 

Synthetic  Theater  of  War  in  Europe 

STT 

Single  Target  Track 

TBD  - 

To  Be  Determined 

TRACE 

Transatlantic  Research  into  Air  Combat  Engagements  Program 

TSPG  - 

Training  Systems  Product  Group 

TWS  - 

Track  While  Scan 

UAV 

Unmanned  Air  Vehicle 

UDP/IP  - 

User  Datagram  Protocol/Intemet  Protocol 

USAF  - 

United  States  Air  Force 

USD(A&T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology 

UTD  - 

Unit  Training  Device 

VBMS 

Virtual  Battlefield  Management  System 

VLO 

Verbundene  Luftkampf  Operationen  (German  long  haul  network  simulation  program) 

VVI 

Vertical  Velocity  Indicator 

WAN  - 

Wide  Area  Network 

WASIF 

Weapon  System  Simulation  in  Flight 

WOW  - 

Weight  on  Wheels 

WPAFB  - 

Wright-  Patterson  Air  Force  Base 

WVR  - 

Within  Visual  Range 
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9.  Appendix  A  -  SNAP  Measurements  [AFRL] 


Date 

Network 

Protocol 

Implementatio 

n 

Latency  (DASA  to 
WL) 

Latency  (WL  to 
DASA) 

30  October 
1996 

ISDN  (64K) 

DIS  2.0.4 

DASA 

Average:  95.7  ms 

Min:  83.4  ms 

Max:  127.4  ms 

Stdev:  6.7  ms 

Average:  119.6  ms 

Min:  108.2  ms 

Max:  132.6  ms 

Stdev:  3.8  ms 

31  October 
1996 

DSI  (128K) 

DIS  2.0.4 

DASA 

Average:  131.3  ms 
Min:  122.6  ms 

Max:  169.7  ms 

Stdev:  3.4  ms 

Average:  146.7  ms 

Min:  136.8  ms 

Max:  184.8  ms 

Stdev:  4.0  ms 

17  January 
1997 

4  March  1997 

6  March  1997 

11  March  1997 

DSI  (128K) 

DASA 

DASA 

Average:  141  ms 

bad  GPS 

bad  GPS 

bad  GPS 

noPDU 

bad  GPS 

bad  GPS 

bad  GPS 

14  March  1997 

DSI  (128K) 

DASA 

DASA 

Average:  145.7  ms 

Min:  142.9  ms 

Max:  161.3  ms 

Stdev:  2.3  ms 

noPDU 

14  March  1997 

DSI  (128K) 

DASA 

DASA 

Average:  185.7  ms 

Min:  145.0  ms 

Max:  557.2  ms 

Stdev:  47.7  ms 

Average:  148.7  ms 

Min:  143.2  ms 

Max:  169.8  ms 

Stdev:  5.5  ms 

20  May  1997 

ISDN 

(128K) 

DASA 

DASA 

bad  data 

bad  data 

20  May  1997 

ISDN 

(128K) 

DIS 

VR-Link 

Average:  103.5  ms 

Min:  97.6  ms 

Max:  151.5  ms 

Stdev:  6.9  ms 

Average:  128.5  ms 

Min:  72.4  ms 

Max:  233.4  ms 

Stdev:  29.2  ms 

20  May  1997 

ISDN 

(128K) 

DIS 

VR-Link 

Average:  102.7  ms 

Min:  97.6  ms 

Max:  135.5  ms 

Stdev:  5.5  ms 

Average:  102.9  ms 

Min:  97.4  ms 

Max:  121.3  ms 

Stdev:  5.5  ms 

20  May  1997 

ISDN 

(128K) 

DIS 

VR-Link 

Average:  103.4  ms 

Min:  97.6  ms 

Max:  143.8  ms 

Stdev:  6.4  ms 

Average:  103.2  ms 

Min:  97.4  ms 

Max:  136.7  ms 

Stdev:  6.1  ms 

20  May  1997 

ISDN 

(128K) 

DIS-Lite 

VR-Link 

Average:  97.6  ms 

Min:  30.8  ms 

Max:  207.5  ms 

Stdev:  22.6  ms 

Average:  93.6  ms 

Min:  86.5  ms 

Max:  135.5ms 

Stdev:  7.6  ms 
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20  May  1997 

ISDN 

(128K) 

DASA 

DASA 

bad  data 

bad  data 

21  May  1997 

ISDN 

(128K) 

DIS 

VR-Link 

bad  GPS 

bad  GPS 

22  May  1997 

DSI  (128K) 

DIS 

VR-Link 

bad  software 

bad  software 

22  May  1997 

DSI  (128K) 

DIS 

VR-Link 

bad  software 

bad  software 

22  May  1997 

DSI  (128K) 

DIS-Lite 

VR-Link 

noPDU 

Average:  142.6  ms 

Min:  96.1  ms 

Max:  179.6  ms 

Stdev:  10.0  ms 

22  May  1997 

DSI  (128K) 

DIS-Lite 

VR-Link 

no  PDU 

Average:  142.5  ms 

Min:  89.5  ms 

Max:  213.8  ms 

Stdev:  12.2  ms 

22  May  1997 

DSI  (128K) 

DASA 

DASA 

Average:  161.9  ms 

Min:  155.7  ms 

Max:  210.0  ms 

Stdev:  7.0  ms 

Average:  143.5  ms 

Min:  138.5  ms 

Max:  203.6  ms 

Stdev:  7.3  ms 

22  May  1997 

DSI  (128K) 

DASA 

DASA 

Average:  160.9  ms 

Min:  156.0  ms 

Max:  243.3  ms 

Stdev:  10.9  ms 

Average:  143.1  ms 

Min:  138.3  ms 

Max:  195.6  ms 

Stdev:  6.3  ms 

28  May  1997 

DSI  (128K) 

DIS-Lite 

VR-Link 

no  PDU 

Average:  144.0  ms 

Min:  137.9  ms 

Max:  200.0  ms 

Stdev:  5.7  ms 

28  May  1997 

DSI  (128K) 

DASA 

DASA 

Average:  128.2  ms 

Min:  125.1  ms 

Max:  158.2  ms 

Stdev:  3.8  ms 

Average:  141.9  ms 

Min:  137.3  ms 

Max:  157.4  ms 

Stdev:  5.7  ms 

Table  9-1:  SNAP  Measurements 
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10.  Appendix  B  -  Pilot  Questionnaires  [Dasa  &  AFRL1 

10.1  Debriefing  of  the  German  Pilot  [Dasa] 

10.1.1  Test  Run  Debriefing  Questionnaire 

10.1.1.1  Simulation  System 

Did  you  feel  your  situational  awareness  was  adequate?  If  not,  what  problems  did  you  experience? 

=>  yes 

=>  RWR  excellent 

=>  radar  contacts  outside  of  40  NM  would  be  nice 
=>  Bullseye  function  would  be  useful 

Realizing  this  is  a  research  facility,  was  the  look  and  feel  of  the  cockpit  acceptable?  If  no,  why  not? 

=>  yes 

=>  excellent  cockpits 

Was  the  aircraft  performance  acceptable?  If  no,  why  not? 

=>  DasaA/C  O.K. 

=>  AFRLA/C  performance  was  too  good.,  radar  was  too  perfect 
=>  best  results  will  be  achieved 

Was  the  sensor  system  performance  acceptable?  If  no,  why  not? 

=>  yes 

=?>  good  overall 

=>  combat  display  and  radar  excellent 

Was  the  missile  and/or  gun  system  performance  acceptable?  If  no,  why  not? 

AFRL  performance  was  too  good 
=>  missile  performance  good 

Was  the  pilot  communications  acceptable?  If  no,  why  not? 

=>  yes 

=>  local  communication  was  excellent ,  USA/BRD  not  used 
=>  intern,  line  not  perfect  but  greatly  improved 
=>  AFRL  cockpits  were  not  loud  enough,  console  was  too  loud 
=>  local  and  intern,  communication  was  much  better  on  last  day ,  actually  real  good 
Was  there  anything  in  the  simulation  that  prevented  you  from  performing  a  tactic  normally 
performed  in  a  real  aircraft  system? 

*  ^=>  Dasa  systems  are  pretty  realistic  for  modem  fighters 

=>  AFRL  systems  were  too  good  and  too  perfect 
=>  the  difference  was  too  high 
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=>  for  a  real  tactical  outcome  you  should  have  similar  systems  in  realism  on  both  sides  and  real 
performance  data 

because  of  unrealistic  AFRL- A/C  performance  normal  tactics  were  not  possible 
=>  I AC AN/Bullseye  function  is  mandatory 

10.1.1.2  Network  Targets 

Was  the  sensor  target  tracking  fidelity  acceptable? 

=>  it  was  really  good  but  too  good  compared  to  real  systems ,  especially  the  AFRL  one 
=>  very  good  with  lock  on 
=>  contacts  sometimes  unstable  but  realistic 
Was  the  visual  target  tracking  fidelity  acceptable? 

=>  the  dome  was  O.K. 

=>  the  VLO-Cockpit  was  not  good  enough 

=>  with  the  VLO-cockpit  visual  fights  are  very  difficult  due  to  screen  limitations.  Perhaps  a  small  screen 
on  each  side  of  the  cockpit  to  check  left  and  right  side  of  the  flight  path  would  help 

=>  good  within  JNM ,  outside  JNM  not  really  useable  *  not  acceptable  for  short  range  scenario 
=>  no,  the  resolution  of  the  visual  system  is  too  marginal  for  this  purpose 

10.1.1.3  General  Issues 

Any  problems  with  this  test  scenario  not  mentioned  above? 

=>  no 

What  additional  thoughts  do  you  have  about  today’s  configuration? 

=>  get  same  performance  data  and  use  realistic  data 

=>  for  future  scenarios  you  should  simulate  real  performance  to  play  i.e.F-4  vs.  F-15 

for  an  operational  model  there  must  be  a  coordinated  initialization  procedure  and  an  administrator 
being  responsible  for  A/C  and  weapon  performance  databases 

=>  however ,  it  is  depending  on  all  participating  players  and  their  systems.  There  is  the  need  of  high 
standardization  of  the  protocol ,  databases  and  subsystems ,  responsible  for  the  administrative  part 

What  is  your  overall  impression  of  this  simulation  scenario? 

=>  With  the  above  mentioned  restrictions  it  should  be  very  interesting  with  a  good  practical  training 
outcome 

=>  overall  very  good ,  however  due  to  unreal  A/C-performance  not  all  tactical  aspects  could  be  evaluated 

=>  national  security  interests  will  be  difficult  to  combine 

=>  can  data  be  secured  in  the  phone  net  or  do  we  need  a  separate  one 

10.1.2  Final  Debriefing  Questionnaire 

The  work  out  while  this  questionnaire  shifts  to  a  general  discussion.  The  results  on  that  is  summarized  in  the 
translated  abstract  of  the  official  report  of  OLT  Kleinheyer 

10.1.2.1  Application  Issues 

1.  Do  you  feel  long-haul  networking  would  be  useful  in  conducting  joint  training  simulation  exercises  at  the 
engagement  level? 
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2.  Do  you  feel  long-haul  networking  would  be  useful  in  evaluating  new  weapon  system  development? 

3.  Do  you  feel  long-haul  networking  could  be  useful  in  conducting  a  joint  mission? 

4.  Would  long-haul  networking  be  more  useful  if  classified  systems  are  used? 

5.  Would  long-haul  networking  be  useful  for  any  other  application? 

10.1.2.2  General  Issues 

1.  Overall,  was  there  anything  that  caused  significant  problems  for  you  during  the  test  runs? 

2.  What  is  your  overall  impression  of  networked  simulations? 

3.  Do  you  have  any  additional  comments  or  suggestions? 

10.1.3  Report  of  OLT  Kleinheyer 

The  following  is  a  translated  abstract  of  the  official  report  of  OLT  Kleinheyer  to  the  BWB  which  summarizes 
the  daily  debriefing  nearly  completely.  Statements  which  are  not  covered  by  this  report  are  worked  out  in  the 
last  of  these  chapters. 

10.1.3.1  The  Experimental  System 

It  was  proved  that  a  stable  transatlantic  connection  is  possible  without  any  restrictions. 

The  developed  training  scenarios  were  very  realistic  and  well  suited  to  the  evaluation  of  the  configured  system. 

10.1.3.2  The  Evaluation  of  the  TRACE  Program  and  a  Connected  Training  Facility  in 
general 

The  tactical  training  together  with  and  against  the  US-pilots  was  possible  with  a  high  degree  of  effectiveness 
even  with  very  little  preparation  time  and  briefing  phase  over  the  telephone. 

After  a  familiarization  phase,  the  ability  of  the  pilots  increased  especially  with  the  use  of  BVR- weapons.  The 
situational  awareness  of  the  crews  improved  during  the  production  runs. 

Basically,  the  interconnection  of  manned  simulations,  when  compared  to  a  single  full  mission  simulator, 
increases  the  tactical  training  possibilities. 

The  knowledge  and  the  tactical  behavior  of  an  opponent  has  human  factors  and  are  thus  even  more  realistic. 
This  means  that  you  can  achieve  the  highest  grade  on  tactical  reality.  Additionally,  the  coordination  and 
communication  of  the  own  forces  (2-,  3-,  4-ship)  can  be  practiced  and  debriefed  effectively. 

This  leads  to  high  training  graduation  and  standardization  within  the  joining  units.  Because  of  these  reasons,  at 
least  a  national  simulator  connection  should  be  strived  for. 

A  interconnection  of  flight  simulators  in  the  role  of  fighters  is  desirable  anyway.  From  the  point  of  view  of  a 
fighter  pilot,  the  following  components  of  an  air  combat  engagement  should  be  added: 

•  GCI, 

•  fighter  bomber, 

•  computer  generated  SAM, 

•  ECR, 

•  bomber, 

•  RECCE, 

•  the  connectivity  of  the  full  mission  simulator,  which  normally  acts  as  a  single  standalone  unit. 


Furthermore,  additonal  points  to  conside  for  interconnected  training  are: 

1 .  Because  a  force  unit’s  normal  size  for  tactical  training  is  up  to  4  aircraft,  there  should  be  at  least  4  simulators 
connected  within  one  local  unit,  including  a  possible  full  mission  simulator. 
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2.  There  is  a  potential  need  for  a  powerful  editing  and  managing  tool  in  the  form  of  a  scenario  manager  for 
effective  preparation,  instruction  and  evaluation  of  training  with  interconnected  simulations  on  complex 
scenarios.  Without  such  a  system  the  learning  effect  for  trainees  would  be  severely  decreased  and  the  full 
spectrum  of  the  connected  simulators  could  not  be  achieved.  A  windows  oriented  desktop  would  be  advised. 

3.  Any  of  these  scenario  managers  should  be  designed  to  be  used  standalone  as  well  as  the  master  of  the  entire 
simulation  scenario.  That  means  that  every  unit  has  the  possibility  to  act  on  its  own  interests  and  initiatives. 
This  could  allow  for  a  great  deal  of  flexibility  and  work  distribution  of  an  interconnected  Simulation. 

4.  The  success  of  such  a  low  cost  simulation  would  depend  decidedly  on  a  compromise  between  the  cockpit 
layouts  of  the  expensive  full  mission  simulator  and  a  low  cost  solution.  The  decision  on  what  functionality 
has  to  be  integrated  and  its  realization  can  only  be  done  in  cooperation  with  operational  pilots.  The  layout  of 
the  cockpit  must  be  selected  based  on  the  best  solution  for  the  resulting  quality  for  the  tactical  training  and 
not  based  solely  on  the  acceptance  of  the  aircraft  crew. 

5.  A  connecting  technology  is  only  reasonable  if  there  are  no  restrictions  on  the  training  effects  because  of 
security  concerns.  That  means  that  it  must  be  possible  to  base  the  running  simulation  of  the  real  data  of  all 
involved  weapon  systems.  Only  training  with  realistic  weapon  and  aircraft  performance  simulations  leads  to 
tactical  knowledge. 

6.  There  has  to  be  a  solution  for  a  low  cost  360  degree  out  of  the  window  view,  which  enables  the  wingman  to 
perform  formation  flight. 

10.1.3.3  Interconnected  Simulation  Training  and  Possible  Problems  for  the 
Operational  Use 

1.  A  cluster  of  up  to  four  locally  networked  simulators  would  be  reasonable  for  units  with  2-,  3-  or  4-ships 
training  against  CGFs.  This  would  be  an  of  advantage,  especially  for  younger  crews  practicing  tactical 
maneuvers  immediately  after  their  type  rating.  The  coordination  and  the  means  of  communication  would  be 
the  emphasis  in  such  training. 

2.  The  next  step  would  then  involve  more  and  more  military  units  (as  other  air  forces,  GCI,  etc.).  The  whole 
mechanism  of  national  training  could  then  be  practiced.  The  national  standards  would  increase  to  a  higher 
level  and  tactical  airborne  flight  preparation  without  any  examples  from  the  pastcould  be  realized.  A  tactical 
simulator  interconnection  essentially  contributes  to  the  ability  of  future  crews. 

3.  At  least  the  interconnection  between  NATO-nations  is  a  logical  conclusion  and  follow-on  of  the  work  done. 
There  is  then  a  need  for  a  MOU  concerning  the  handling  of  basic  data.  Standardized  regulations  of  all 
participants  has  to  be  achieved. 

10.2  Debriefing  of  the  US  Pilot  [AFRL1 

10.2.1  Test  Run  Debriefing  Questionnaire 

10.2.1.1  Simulation  System 

Did  you  feel  your  situational  awareness  was  adequate?  If  not,  what  problems  did  you  experience? 

=>  Most  answers  yes . 

=>  Virtual  EFOV  helpful 

=>  Improve  by  showing  target  aspect  in  HUD  (when  locked) 

=>  Couldn't  see  other  aircraft  when  outside  forward  screen  FOV 

=>  Need  aspect  carat  and  AMRAAM  Rl/R2/Rmax. 

=>  Virtual  wingman/bogey  in  HUD  doesn  ’t  agree  with  HDD  ( unknown  vs  F-22) 

=>  Need  threat  missile  status.  Range  info  on  threat  missile. 

=>  MCS  inadequate  in  within  visual  range. 
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Realizing  this  is  a  research  facility,  was  the  look  and  feel  of  the  cockpit  acceptable?  If  no,  why  not? 

=>  All  answers  yes. 

=>  Need  RWR  display  with  range  and  azimuth  info  on  threat  missiles. 

=>  Excellent  coordination  between  German/American  2-ships  (scenario  5.2) 

Was  the  aircraft  performance  acceptable?  If  no,  why  not? 

=>  Optimistic.  Accelerating  at  M  1.2  in  steep  climb. 

=>  Mil  power  climb  and  acceleration  were  weak. 

=>  Great  top  end  accelerations 

=>  Too  good \  Accelerating  supersonic  at  30  deg.  nose  up 

Was  the  sensor  system  performance  acceptable?  If  no,  why  not? 

Yes 

=>  Too  good 

=>  Not  realistic  —  too  simple. 

Was  the  missile  and/or  gun  system  performance  acceptable?  If  no,  why  not? 

=>  Missile  launch  zones  (maximum  engagement  distance  =  Rl)  appeared  too  short.  Launched  missile 
and  had  it  reach  target  outside  of  the  max  launch  cue. 

=>  Missile  max  kinematic  capability  was  not  realistically  displayed  on  HUD  or  HDD 
=>  Gun  lagged  pipper 

Was  the  pilot  communications  acceptable?  If  no,  why  not? 

=>  Volume  too  low. 

=>  OK 

=>  Could  hear  opponents  control  room 

Was  there  anything  in  the  simulation  that  prevented  you  from  performing  a  tactic  normally 
performed  in  a  real  aircraft  system? 

=>  Most  answers  no. 

No  wrap  around  video/limited  FOV 
=>  Could  do  more  tactically  that  in  an  F-15 
z=>  MLE  bad...  No  Rmaxl,  Rmax2.  Envelope  jitters. 

=>  Lofted  steering  for  MRM  missiles  was  not  modeled. 

=>  Chaff  in  scenario  4B. 

=>  No  bullseye  data. 

=>  RWR  info 

10.2.1.2  Network  Targets 

Was  the  sensor  target  tracking  fidelity  acceptable? 

,  all  answers  yes 

=>  One  pilot  felt  it  was  too  good  to  be  true. 

Was  the  visual  target  tracking  fidelity  acceptable? 

=>  most  answers  yes 
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:=>  Minor  location  changes  (jumps)  were  noticeable . 

=>  Fuzzy  video  in  dome  but  acceptable. 

10.2.1.3  General  Issues 

Any  problems  with  this  test  scenario  not  mentioned  above? 

=>  Most  answers  no 

=>  His  missile  (launched  outside  30  nm)  was  able  to  chase  this  aircraft  down  in  the  beam .  This  is  a  very 
“high  performance  ”  missile. 

What  additional  thoughts  do  you  have  about  today’s  configuration? 

=>  Good 

=>  Make  Rl,  R2  cues  more  accurate 
What  is  your  overall  impression  of  this  simulation  scenario? 

=>  Good 

Fine  for  BVR 

10.2.2  Final  Debriefing  Questionnaire 
10.2.2.1  Application  Issues 

Do  you  feel  long-haul  networking  would  be  useful  in  conducting  joint  training  simulation  exercises 
at  the  engagement  level? 

=>  All  yes 

=>  BVR  with  realistic  models  for  aero ,  sensors ;  weapons ,  and  terrain. 

=>  Absolutely.  Impressive 

=>  Security  issues  require  a  lot  of  work  but  if  overcome  the  whole  act  should  be  real  useful. 

Do  you  feel  long-haul  networking  would  be  useful  in  evaluating  new  weapon  system  development? 

=>  All  yes 

=?  If  you  have  realistic  missiles. 

=>  Classification  level  might  make  this  difficult. 

=>  Avionics  and  other  PVI  is  form  fit  for  this  type  testing/evai 

=>  In  the  sense  of  larger  scale  man-in-the-loop  sim.  and  eval.  It  would  be  useful.  New  weapons  need  to 
be  evaluated  at  the  mission  and  campaign  level. 

Do  you  feel  long-haul  networking  could  be  useful  in  conducting  a  joint  mission? 

=>  Yes 

=>  with  realistic  models 

Would  long-haul  networking  be  more  useful  if  classified  systems  are  used? 

Yes 

=>  realistic  models 

— >  Classified  systems  will  be  absolute  requirements.  Utility  will  be  extremely  limited  at  the  unclass  level. 
Would  long-haul  networking  be  useful  for  any  other  application? 
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=>  Mission  rehearsal 
=>  Battlefield  management,  Intel 

=>  International/NATO  air  refueling  procedures  practice. 

=>  Training.  Tactics  development.  Concept  exploration.  Help  reduce  costs. 

10.2.2.2  General  Issues 

Overall,  was  there  anything  that  caused  significant  problems  for  you  during  the  test  runs? 

=>  Better  coordination  ahead  of  time  to  minimize  waiting  time  and  comm  load 

=>  During  large  engagements  (6  vs  many ,  etc)  no  RWR/spikes  transmitted  (bandwidth  limitation) 

=>  Limited  bandwidth. 

What  is  your  overall  impression  of  networked  simulations? 

=>  Networking  is  fine  if  the  simulations  at  the  ends  work. 

=>  Excellent  possibilities  for  training 

=>  Excellent  —  great  improvement  over  previous  attempts. 

=>  Very  nice. 

Do  you  have  any  additional  comments  or  suggestions? 

=>  System  testing  or  training  procedures  should  be  planned  to  more  detail  prior  to  going  real-time. 
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11.  Appendix  C  -  Scenario  Simulation  Data  tDASA] 

11.1  Scenario  1 

***************  START  SCENARIO  ****************************************** 

ScenarioName  /usr/people/SM/SCENARIOS/TRACE/S  1  .dir/S  1  .sen 
************************************************************************* 

NoUnits  2 

_ FLOT  with  2  points - 

0  Lat  36.997612  Lon  -1 14.370201 
1  Lat  35 .054893  Lon -114.5 11 803 

ENTITY  Role  Description 
No  Meaning 
0  NEUTRAL_ROLE 

1  BOMBER 

2  FIGHTER 

3  DETACHED  ESCORT 

4  CLOSE  ESCORT 

5  RECCE 

6  STANDOFFJAMMER 

7  AWACS 

ENTITY  Force  Description 
No  Meaning 
0  NEUTRAL 

1  BLUE 

2  RED 

ENTITY  Kind  Description 
No  Meaning 
0  OTHER 

1  PLATFORM 

2  MUNITION 
ENTITY  Domain  Description 
No  Meaning 

0  OTHER 

1  LAND 

2  AIR 

3  SURFACE 

Path  /usr/people/SM/SCENARIOS/TRACE/S  1  .dir  EntityName  C  AP_WL 
MANNED  Entity:  Siteld  12  Appld  1  Entld  0  Frcld  1  Roleld  2 
_ POSITION/ATTITUDE  SPEED - 

Lat  36.329945  Lon  -1 15.569717  Alt/meter  2209.759644  Heading  90.000  speed/knots  0.000  Fuel  3600.000000 
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EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S  1  .dir  EntityName  CAP_DASA 
MANNED  Entity:  Siteld  1 1  Appld  0  Entld  0  Frcld  1  Roleld  2 
- POSmON/ATTITUDE  SPEED - 

Lat  36.329693  Lon  -1 15.569092  Alt/meter  2209.759644  Heading  90.000  speed/knots  0.000  Fuel  3600.000000 
EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

*****************  END  SCENARIO  ***************************************** 


11.2  Scenario  2 

***************  START  SCENARIO  ****************************************** 
ScenarioName  /usr/people/SM/SCENARIOS/TRACE/S2.dir/S2.scn 
************************************************************************* 

NoUnits  2 

- -  FLOT  with  2  points - 

0  Lat  36.997612  Lon -114.370201 
1  Lat  35.054893  Lon -114.51 1803 


ENTITY  Role  Description 
No  Meaning 
0  NEUTRAL.ROLE 

1  BOMBER 

2  FIGHTER 

3  DETACHED  ESCORT 

4  CLOSE  ESCORT 

5  RECCE 

6  STANDOFFJAMMER 
7.  AWACS 

ENTITY  Force  Description 
No  Meaning 
0  NEUTRAL 
1  BLUE 
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2  RED 

ENTITY  Kind  Description 
No  Meaning 
0  OTHER 

1  PLATFORM 

2  MUNITION 
ENTITY  Domain  Description 
No  Meaning 

0  OTHER 

1  LAND 

2  AIR 

3  SURFACE 

Path  /usr/people/SM/SCENARIOS/TRACE/S2.dir  EntityName  CAP_WL 
MANNED  Entity:  Siteld  12  Appld  1  Entld  0  Frcld  1  Roleld  2 
- POSITION/ ATTITUDE  SPEED - 

Lat  36.329945  Lon  -1 15.569717  Alt/meter  2209.759644  Heading  90.000  speed/knots  0.000  Fuel  3600.000000 
EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR.MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S2.dir  EntityName  CAP_DASA 
MANNED  Entity:  Siteld  1 1  Appld  0  Entld  0  Frcld  2  Roleld  2 
- POSITION/ ATTITUDE  SPEED - 

Lat  36.431980  Lon  -1 14.275795  Alt/meter  4632.875391  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- — -  WEAPONS - 

SR_MISSILE:  Qty  4 
MR.MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

*****************  END  SCENARIO  ***************************************** 
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11.3  Scenario  3A 

***************  START  SCENARIO  ****************************************** 

ScenarioName  /usr/peop!e/SM/SCENARIOS/TRACE/S3A.dir/S3A.scn 

NoUnits  4 

- - FLOT  with  2  points - 

0  Lat  36.997612  Lon -114.370201 
1  Lat  35.054893  Lon -114.5 11 803 

ENTITY  Role  Description 
No  Meaning 
0  NEUTRAL_ROLE 

1  BOMBER 

2  FIGHTER 

3  DETACHED  ESCORT 

4  CLOSE  ESCORT 

5  RECCE 

6  STANDOFFJAMMER 

7  AW  ACS 

ENTITY  Force  Description 
No  Meaning 
0  NEUTRAL 

1  BLUE 

2  RED 

ENTITY  Kind  Description 
No  Meaning 
0  OTHER 

1  PLATFORM 

2  MUNITION 
ENTITY  Domain  Description 
No  Meaning 

0  OTHER 

1  LAND 

2  AIR 

3  SURFACE 

Path  /usr/people/SM/SCENARIOS/TRACE/S3A.dir  EntityName  CAP_WL1 
MANNED  Entity:  Siteld  12  Appld  1  Entld  0  Frcld  1  Roleld  2 
- POSmON/ATTITUDE  SPEED - 

L'at  36.329693  Lon  -1 15.569092  Alt/meter  2209.759644  Heading  90.000  speed/knots  0.000  Fuel  3600.000000 
EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 


11-4 


Transatlantic  Research  into  Air  Combat  Engagements  Final  Report 

Doc.-No.:  Dasa-S-R- 1775-02  _ 1 1 .  Appendix  C  -  Scenario  Simulation  Data _ 

MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S3A.dir  EntityName  CAP_DASA1 
MANNED  Entity:  Siteld  1 1  Appld  0  Entld  0  Frcld  2  Roleld  2 
_ POSmON/ATTITUDE  SPEED - 

Lat  36.609104  Lon  -1 14.136975  Alt/meter  457 1 .916504  Heading  290.000  speed/knots  420.000  Fuel 
3600.000000 

Entity  Type:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  2 
GUN:  Rounds  150 

- EW - 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S3A.dir  EntityName  CAPJWL2 
MANNED  Entity:  Siteld  12  Appld  1  Entld  1  Frcld  1  Roleld  2 
_ POSITION/ATnTUDE  SPEED - 

Lat  36.329945  Lon  -1 15.569717  Alt/meter  2209.759644  Heading  90.000  speed/knots  0.000  Fuel  3600.000000 
Entity  Type:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S3A.dir  EntityName  CAP_DASA2 
MANNED  Entity:  Siteld  1 1  Appld  3  Entld  0  Frcld  2  Roleld  2 
_ POSmON/ATTOUDE  SPEED - 

Lat  36.598141  Lon  -114.140966  Alt/meter  4571.916504  Heading  290.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  2 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

*****************  SCENARIO  ***************************************** 
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11.4  Scenario  3B 

***************  START  SCENARIO  ****************************************** 
ScenarioName  /usr/people/SM/SCENARIOS/TRACE/S3B.dir/S3B.scn 
************************************************************************* 

NoUnits  4 

- FLOT  with  2  points - 

0  Lat  36.997612  Lon -114.370201 
1  Lat  35.054893  Lon -114.51 1803 


ENTITY  Role  Description 
No  Meaning 
0  NEUTRAL_ROLE 

1  BOMBER 

2  FIGHTER 

3  DETACHED  ESCORT 

4  CLOSE  ESCORT 

5  RECCE 

6  STANDOFFJAMMER 

7  AW  ACS 

ENTITY  Force  Description 
No  Meaning 
0  NEUTRAL 

1  BLUE 

2  RED 

ENTITY  Kind  Description 
No  Meaning 
0  OTHER 

1  PLATFORM 

2  MUNITION 
ENTITY  Domain  Description 
No  Meaning 

0  OTHER 

1  LAND 

2  AIR 

3  SURFACE 

Path  /usr/people/S  M/SCENARIOS/TRACE/S3B.dir  EntityName  CAP_WL1 
MANNED  Entity:  Siteld  12  Appld  1  Entld  0  Frcld  2  Roleld  2 
- POSmON/ATTITUDE  SPEED - 

Lat  36.609 1 04  Lon  - 1 14. 1 36975  Alt/meter  457 1 .9 1 6504  Heading  290.000  speed/knots  420.000  Fuel 
3600.000000 

Entity  Type:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 
- WEAPONS - - - 
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SR.MISSILE:  Qty  4 
MR_MISSILE:  Qty  2 
GUN:  Rounds  150 

- EW - 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S3B.dir  EntityName  CAP_DASA1 
MANNED  Entity:  Siteld  1 1  Appld  0  Entld  0  Frcld  1  Roleld  2 
- POSmON/ATTITUDE  SPEED - 

Lat  36.329693  Lon  -1 15.569092  Alt/meter  2209.759644  Heading  90.000  speed/knots  0.000  Fuel  3600.000000 
EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S3B.dir  EntityName  CAP_WL2 
MANNED  Entity:  Siteld  12  Appld  1  Entld  1  Frcld  2  Roleld  2 
- POSmON/ ATTITUDE  SPEED - 

Lat  36.598141  Lon  -1 14.140966  Alt/meter  4571.916504  Heading  290.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  2 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  /usr/people/SM/SCENARIOS/TRACE/S3B.dir  EntityName  CAP_DASA2 
MANNED  Entity:  Siteld  1 1  Appld  3  Entld  0  Frcld  1  Roleld  2 
- POSITION/ATTITUDE  SPEED - 

Lat  36.329945  Lon  -1 15.569717  Alt/meter  2209.759644  Heading  90.000  speed/knots  0.000  Fuel  3600.000000 
EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR.MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

*****************  end  SCENARIO  ***************************************** 
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11.5  Scenario  4A 

***************  START  SCENARIO  ****************************************** 
ScenarioName  S4A.dir/S4A.scn 

************************************************************************* 

NoUnits  8 

- FLOT  with  2  points - 

0  Lat  36.988068  Lon  -1 14.376099 
1  Lat  35.064438  Lon  -1 14.505898 


ENTITY  Role  Description 
No  Meaning 
0  NEUTRALJROLE 

1  BOMBER 

2  FIGHTER 

3  DETACHED  ESCORT 

4  CLOSE  ESCORT 

5  RECCE 

6  STANDOFFJAMMER 

7  AWACS 

ENTITY  Force  Description 
No  Meaning 
0  NEUTRAL 

1  BLUE 

2  RED 

ENTITY  Kind  Description 
No  Meaning 
0  OTHER 

1  PLATFORM 

2  MUNITION 
ENTITY  Domain  Description 
No  Meaning 

0  OTHER 

1  LAND 

2  AIR 

3  SURFACE 

Path  S4A.dir  EntityName  BOMBER_CGT4 

UNMANNED  Entity:  Siteld  1 1  Appld  4  Entld  0  Frcld  2  Roleld  1 

- POSmON/ATTITUDE  SPEED - 

Lat  35.999920  Lon  -1 14.098793  Alt/meter  1066.780518  Heading  310.000  speed/knots  480.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 
- WEAPONS - 
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SR_MISSILE:  Qty  4 
FREEFALL_BOMB:  Qty  8 

- - EW - 

FLARE:  Qty  30 

_ WAYPOINT  ROUTE  - 

WPTROUTE  nziel  6  nwpt  7 
WPOINT  0  Active  1  Lat  36.003582  Lon  -1 14.129776 
WPOINT  1  Active  1  Lat  36.195702  Lon  -1 14.376099 
WPOINT  2  Active  1  Lat  36.08 1 146  Lon  - 1 1 4.830406 
WPOINT  3  Active  1  Lat  36.193317  Lon  -1 15.063461 
WPOINT  4  Active  1  Lat  36.133652  Lon  -1 15.452866 
WPOINT  5  Active  1  Lat  36.331741  Lon  -1 15.547272 
WPOINT  6  Active  1  Lat  36.233891  Lon  -1 14.296448 

Path  S4A.dir  EntityName  CAP_WL2 

MANNED  Entity:  Siteld  12  Appld  1  Entld  0  Frcld  1  Roleld  2 
_ _ POSITION/ATTITUDE  SPEED - 

Lat  36.248249  Lon  -1 15.498596  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR.MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4A.dir  EntityName  CAP_CGT1 

UNMANNED  Entity:  Siteld  1 1  Appld  4  Entld  1  Frcld  1  Roleld  2 
_ POSITION/ATTITUDE  SPEED - 

Lat  36.233891  Lon  -1 15.498291  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4A.dir  EntityName  ESCORT_DASA2 

MANNED  Entity:  Siteld  1 1  Appld  3  Entld  0  Frcld  2  Roleld  3 

_ POSmON/ATTITUDE  SPEED - 
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Lat  36.344395  Lon  -1 14.098793  Alt/meter  1828.766602  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4A.dir  EntityName  CAP_WL1 

MANNED  Entity:  Siteld  12  Appld  1  Entld  1  Frcld  1  Roleld  2 
- POSmON/ATTTTUDE  SPEED - 

Lat  36.264915  Lon  -1 15.498596  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSELE:  Qty  4 
MR.MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4A.dir  EntityName  CAP_CGT2 

UNMANNED  Entity:  Siteld  1 1  Appld  4  Entld  2  Frcld  1  Roleld  2 
- POSmON/ATHTUDE  SPEED - 

Lat  36.279236  Lon  -1 15.498001  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4A.dir  EntityName  BOMBER_CGT3 

UNMANNED  Entity:  Siteld  2  Appld  2  Entld  0  Frcld  2  Roleld  1 

- POSITION/ ATTITUDE  SPEED - 

Lat  36.016587  Lon  -1 14.098793  Alt/meter  1066.780518  Heading  310.000  speed/knots  480.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
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FREEFALL_BOMB :  Qty  8 

- EW - 

FLARE:  Qty  30 

- - WAYPOINT  ROUTE  - — 

WPTROUTE  nziel  6  nwpt  7 
WPOINT  0  Active  1  Lat  36.020287  Lon  - 1 14. 126823 
WPOINT  1  Active  1  Lat  36.202862  Lon  -1 14.373154 
WPOINT  2  Active  1  Lat  36.090691  Lon  -1 14.821556 
WPOINT  3  Active  1  Lat  36.193317  Lon  -1 15.063461 
WPOINT4  Active  1  Lat  36.133652  Lon  -1 15.452866 
WPOINT  5  Active  1  Lat  36.331741  Lon  -1 15.547272 
WPOINT  6  Active  1  Lat  36.233891  Lon  -1 14.296448 

Path  S4A.dir  EntityName  ESCORT_DAS A 1 

MANNED  Entity:  Siteld  1 1  Appld  0  Entld  0  Frcld  2  Roleld  3 

- ^ - POSITION/ ATTITUDE  SPEED - 

Lat  36.333254  Lon  -1 14.098793  Alt/meter  1828.766602  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 
- WEAPONS - 

SR_MISSILE:  Qty  4  ; 

MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

*****************  END  SCENARIO  ***************************************** 

11.6  Scenario  4B 

***************  START  SCENARIO  ****************************************** 
ScenarioName  S4B.dir/S4B.scn 

************************************************************************* 

NoUnits  8 

- FLOT  with  2  points - 

0  Lat  36.988068  Lon  -1 14.376099 
1  Lat  35.064438  Lon  -1 14.505898 


ENTITY  Role  Description 
No  Meaning 
0  NEUTRALJROLE 

1  BOMBER 

2  FIGHTER 

3  DETACHED  ESCORT 

4  CLOSE  ESCORT 

5  RECCE 
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6  STANDOFFJAMMER 

7  AW  ACS 

ENTITY  Force  Description 
No  Meaning 
0  NEUTRAL 

1  BLUE 

2  RED 

ENTITY  Kind  Description 
No  Meaning 
0  OTHER 

1  PLATFORM 

2  MUNITION 
ENTITY  Domain  Description 
No  Meaning 

0  OTHER 

1  LAND 

2  AIR 

3  SURFACE 

Path  S4B.dir  EntityName  BOMBER_CGT4 

UNMANNED  Entity:  Siteld  1 1  Appld  4  Entld  0  Frcld  2  Roleld  1 

_ POSmON/ATTITUDE  SPEED - 

Lat  35.999920  Lon  -1 14.098793  Alt/meter  1066.780518  Heading  310.000  speed/knots  480.000  Fuel 
3600.000000 

Entity  Type:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
FREEFALLJ3 OMB :  Qty  8 

- EW - 

FLARE:  Qty  30 

_ WAYPOINT  ROUTE - 

WPTROUTE  nziel  6  nwpt  7 
WPOINT  0  Active  1  Lat  36.003582  Lon  -1 14.129776 
WPOINT  1  Active  1  Lat  36. 195702  Lon  - 1 14.376099 
WPOINT  2  Active  1  Lat  36.081 146  Lon  -1 14.830406 
WPOINT  3  Active  1  Lat  36.193317  Lon  -1 15.063461 
WPOINT  4  Active  1  Lat  36.133652  Lon  -1 15.452866 
WPOINT  5  Active  1  Lat  36.331741  Lon  -1 15.547272 
WPOINT  6  Active  1  Lat  36.233891  Lon  -1 14.296448 

Path  S4B.dir  EntityName  CAP_CGT1 

UNMANNED  Entity:  Siteld  1 1  Appld  4  Entld  1  Frcld  1  Roleld  2 
_ POSITION/ATTITUDE  SPEED - 
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Lat  36.233891  Lon  -1 15.498291  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSELE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4B.dir  EntityName  CAP_DASA1 

MANNED  Entity:  Siteld  1 1  Appld  0  Entld  0  Frcld  1  Roleld  2 

_ POSITION/ATTITUDE  SPEED - 

Lat  36.264915  Lon  -1 15.498596  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - -- 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4B.dir  EntityName  CAP_DASA2 

MANNED  Entity:  Siteld  1 1  Appld  3  Entld  0  Frcld  1  Roleld  2 

_ POSITION/ATTITUDE  SPEED - 

Lat  36.248249  Lon  -1 15.498596  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR.MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4B.dir  EntityName  CAP_CGT2 

UNMANNED  Entity:  Siteld  1 1  Appld  4  Entld  2  Frcld  1  Roleld  2 
_ POSITION/ATTITUDE  SPEED - 

Lat  36.279236  Lon  - 1 15.498001  Alt/meter  3657.533203  Heading  90.000  speed/knots  500.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
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MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4B.dir  EntityName  BOMBER_CGT3 

UNMANNED  Entity:  Siteld  2  Appld  2  Entld  0  Frcld  2  Roleld  1 

- POSmON/ATTITUDE  SPEED - 

Lat  36.016587  Lon  -1 14.098793  Alt/meter  1066.780518  Heading  310.000  speed/knots  480.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
FREEFALLJBOMB:  Qty  8 

- EW - 

FLARE:  Qty  30 

- WAYPOINT  ROUTE  - 

WPTROUTE  nziel  6  nwpt  7 
WPOINT  0  Active  1  Lat  36.020287  Lon  - 1 14. 1 26823 
WPOINT  1  Active  1  Lat  36.202862  Lon  -1 14.373154 
WPOINT  2  Active  1  Lat  36.090691  Lon  -1 14.821556 
WPOINT  3  Active  1  Lat  36.193317  Lon  -1 15.063461 
WPOINT  4  Active  1  Lat  36.133652  Lon  -1 15.452866 
WPOINT  5  Active  1  Lat  36.331741  Lon  -1 15.547272 
WPOINT  6  Active  1  Lat  36.233891  Lon  -1 14.296448 

Path  S4B.dir  EntityName  ESCORT_WL2 

MANNED  Entity:  Siteld  12  Appld  1  Entld  0  Frcld  2  Roleld  3 

- POSmON/ATTITUDE  SPEED - 

Lat  36.344395  Lon  -1 14-098793  Alt/meter  1 828.766602  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- —WEAPONS - 

SR.MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S4B.dir  EntityName  ESCORT_WLl 

MANNED  Entity:  Siteld  12  Appld  1  Entld  1  Frcld  2  Roleld  3 

- POSmON/ATTITUDE  SPEED - 

Lat  36.333254  Lon  -1 14.098793  Alt/meter  1828.766602  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 
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EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR.MISSBLE:  Qty  4 
MR_M1SSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

*****************  END  SCENARIO  ***************************************** 


11.7  Scenario  5 

***************  START  SCENARIO  ****************************************** 
ScenarioName  S5.dir/S5.scn 

************************************************************************* 
NoUnits  8 

- FLOT  with  2  points - 

0  Lat  36.988068  Lon -114.376099 
1  Lat  35.064438  Lon  - 1 14.505898 


ENTITY  Role  Description 
No  Meaning 
0  NEUTRAL_ROLE 

1  BOMBER 

2  FIGHTER 

3  DETACHED  ESCORT 

4  CLOSE  ESCORT 

5  RECCE 

6  STANDOFFJAMMER 

7  AWACS 

ENTITY  Force  Description 
No  Meaning 
0  NEUTRAL 

1  BLUE 

2  RED 

ENTITY  Kind  Description 
No  Meaning 
0  OTHER 

1  PLATFORM 

2  MUNITION 
ENTITY  Domain  Description 
No  Meaning 

0  OTHER 

1  LAND 

2  AIR 

3  SURFACE 


11-15 


Transatlantic  Research  into  Air  Combat  Engagements  Final  Report 

Doc.-No.:  Dasa-S-R- 1775-02 _ 1 1 .  Appendix  C  -  Scenario  Simulation  Data 


Path  S5.dir  EntityName  CAP_DASA1 

MANNED  Entity:  Siteld  1 1  Appld  0  Entld  0  Frcld  1  Roleld  2 

- POSmON/ATTITUDE  SPEED - 

Lat  36.289021  Lon  -1 15.724564  Alt/meter  457 1.9 16504  Heading  90.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR.MISSILE:  Qty4 
MR_MISSILE:  Qty4 
GUN:  Rounds  300 


FLARE:  Qty  30 

Path  S5.dir  EntityName  CAP_DASA2 

MANNED  Entity:  Siteld  1 1  Appld  3  Entld  0  Frcld  1  Roleld  2 

- POSmON/ATTITUDE  SPEED  — - - 

Lat  36.2482 1 1  Lon  - 1 15.724266  Alt/meter  457 1 .9 1 6504  Heading  90.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

Path  S5.dir  EntityName  CAP_WL1 

UNMANNED  Entity:  Siteld  1  Appld  1  Entld  0  Frcld  1  Roleld  2 
- POSmON/ATTITUDE  SPEED - 

Lat  36.307400  Lon  -1 15.723679  Alt/meter  4571.916504  Heading  90.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- - WEAPONS - - — 

SR_MISSILE:  Qty  4 
MR.MISSILE:  Qty  4 
GUN:  Rounds  150 

- EW - 

FLARE:  Qty  30 


Path  S5.dir  EntityName  RFB02 

UNMANNED  Entity:  Siteld  1 1  Appld  4  Entld  0  Frcld  2  Roleld  1 
- POSmON/ATTITUDE  SPEED - - 
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Lat  35.999920  Lon  -1 14.098793  Alt/meter  1066.780518  Heading  310.000  speed/knots  420.000  Fuel 
3600.000000 

Entity  Type:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
FREEFALL_BOMB:  Qty  8 

- - —  EW - 

FLARE:  Qty  30 

_ WAYPOINT  ROUTE  - 

WPTROUTE  nziel  6  nwpt  7 
WPOINT  0  Active  1  Lat  36.003582  Lon  -1 14.129776 
WPOINT  1  Active  1  Lat  36.1 12171  Lon -1 14.387901 
WPOINT  2  Active  1  Lat  36.081 146  Lon  -1 14.830406 
WPOINT  3  Active  1  Lat  36.193317  Lon  -1 15.063461 
WPOINT  4  Active  1  Lat  36.133652  Lon  -1 15.452866 
WPOINT  5  Active  1  Lat  36.331741  Lon  -1 15.547272 
WPOINT  6  Active  1  Lat  36.233891  Lon  -1 14.296448 

Path  S5.dir  EntityName  RF03 

UNMANNED  Entity:  Siteld  2  Appld  2  Entld  0  Frcld  2  Roleld  3 
- POSITION/ATTITUDE  SPEED - 

Lat  36.372314  Lon  -1 14.101746  Alt/meter  3047.944336  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 

Entity  Type:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SRJMISSILE:  Qty  4 
MR_MISSILE:  Qty  2 

- EW - 

FLARE:  Qty  30 

- WAYPOINT  ROUTE  - 

WPTROUTE  nziel  4  nwpt  5 

WPOINT  0  Active  1  Lat  36.372314  Lon  -1 14.131241 
WPOINT  1  Active  1  Lat  36.252983  Lon  -1 14.346596 
WPOINT  2  Active  1  Lat  36.463009  Lon  -1 14.924805 
WPOINT  3  Active  1  Lat  36.338902  Lon  -1 15.514816 
WPOINT  4  Active  1  Lat  36.1 14559  Lon  -114.328896 

Path  S5.dir  EntityName  RF01 

UNMANNED  Entity:  Siteld  2  Appld  2  Entld  1  Frcld  2  Roleld  3 
- - POSITION/ATTITUDE  SPEED - 

Lat  36.349920  Lon  - 1 14.098793  Alt/meter  3047.944336  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 
- WEAPONS - 
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SR_MISSILE:  Qty  4 
MR_MISSILE:  Qty  2 

- EW - 

FLARE:  Qty  30 

- WAYPOINT  ROUTE  - 

WPTROUTE  nziel  4  nwpt  5 
WPOINT  0  Active  1  Lat  36.349640  Lon  -1 14. 1 17973 
WPOINT  1  Active  1  Lat  36.252983  Lon  -1 14.346596 
WPOINT  2  Active  1  Lat  36.463009  Lon  -1 14.924805 
WPOINT  3  Active  1  Lat  36.338902  Lon  -1 15.514816 
WPOINT  4  Active  1  Lat  36. 1 14559  Lon  -1 14.328896 


Path  S5.dir  EntityName  RF02 

UNMANNED  Entity:  Siteld  2  Appld  2  Entld  2  Frcld  2  Roleld  3 
- POSITION/ATTITUDE  SPEED - 

Lat  36.333254  Lon  -1 14.098793  Alt/meter  3047.944336  Heading  270.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  2 

- WEAPONS - 

SR_MISSILE:  Qty  4 
MR.MISSILE:  Qty  2 

- EW - 

FLARE:  Qty  30 

- WAYPOINT  RQUTE - 

WPTROUTE  nziel  4  nwpt  5 
WPOINT  0  Active  1  Lat  36.331741  Lon  -1 14.1 17973 
WPOINT  1  Active  1  Lat  36.251789  Lon  -1 14.345123 
WPOINT  2  Active  1  Lat  36.458233  Lon  -1 14.926285 
WPOINT  3  Active  1  Lat  36.338902  Lon  -1 15.514816 
WPOINT  4  Active  1  Lat  36. 1 14559  Lon  -1 14.328896 


Path  S5.dir  EntityName  CAP_WL2 

MANNED  Entity:  Siteld  12  Appld  1  Entld  1  Frcld  1  Roleld  2 
- POSITION/ATTITUDE  SPEED - 

Lat  36.267780  Lon  -1 15.723969  Alt/meter  4571.916504  Heading  90.000  speed/knots  420.000  Fuel 
3600.000000 

EntityType:  Kind  1  Domain  2  Country  0  Cat  0  SubCat  0  Specific  1 

- WEAPONS - 

SR.MISSILE:  Qty  4 
MR_MISSILE:  Qty  4 
GUN:  Rounds  300 

- EW - 

FLARE:  Qty  30 

*****************  end  scenario  ***************************************** 
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12.  Appendix  D  -  Selected  Data  Recorded  During  Production  Runs  [DASA] 

Data  recorded  during  production  runs  are  presented  as  trajectory  plots  of  aircraft  and  missiles. 

These  data  have  been  recorded  by  a  program  on  the  simulation  computer  of  the  DASA  dome  cockpit. 


Six  simulation  runs  have  been  evaluated 

•  3  runs  of  scenario  S3  (2  vs  2  manned  cockpits) 

•  3  runs  of  scenario  S5  („Joint  Mission11;  4  manned  cockpits  -  2  Air  Force  Research  Laboratory  and  2  Dasa 
cockpits  -  vs  4  DASA  Computer  Generated  Targets  (CGT). 

12.1  Description  of  Data  Presentation 

The  data  was  taken  every  second  and  recorded  on  a  disk  file. 

The  data  presentation  consists  of  a 

•  trajectory  plot  of  aircraft  and  missiles  in  the  Z-Y-pIane  (altitude  vs  Y-axis) 

(solid  lines  :  aircraft ;  dashed  lines  :  missiles) 

•  trajectory  plot  of  aircraft  and  missiles  in  the  X-Y-plane  (trajectories  projected  into  the  horizontal  plane);  a 
summary  table  of  symbols  used  is  shown  in  Fig.  12- 1 .  Numbers  at  symbols  denote  simulation  time  divided 
by  10. 

•  summary  table  containing  information  of  participating  aircraft  starting  with  side,  role,  cockpit  or  CGT,  time 
of  engagement,  position,  Mach  number  and  heading  at  start  of  plot.  This  is  followed  by  information  about 
fired  missiles.  The  first  row  of  missile  information  present  the  results  of  Medium  Range  Missiles  (MRM), 
the  second  of  Short  Range  Missiles  (SRM). 

These  information  contains: 

I  target  of  missile  (e.g.  B2  =  Blue  2) 

H  on  the  upper  right  side  firing  time  of  missile  is  shown,  and  end  time  of  missile  flight  is  shown  below 
H  last  row  of  numbers  show  miss  distance  : 

true  range  to  target  at  end  of  flight  for  all  except  DASA  dome  cockpit;  for  DASA  dome  cockpit,  as  data 
are  available,  either  true  range  to  target  if  seeker  head  had  „lock  on11  or  apparent  range  to  target  if  seeker 
head  could  not  lock  on  to  target. 

miss  (-2)  or  hit  (-3)  flag  indicating  cause  of  termination  in  case  of  miss 

The  normal  flag  in  case  of  a  missile  hit  is  0.  Negative  status  flags  can  also  be  possible,  as  missile  calculation 
will  be  continued  if  range  to  target  is  less  than  300  m  and  a  negative  status  flag  is  set.  If  the  miss  distance  is 
then  found  to  be  within  lethal  radius,  this  also  results  in  a  legal  missile  hit. 

List  of  terminating  conditions  : 

Medium  Range  Missile 
0  =  normal  flight 

1  =  time  of  flight  less  than  minimum  time  for  warhead  activation 

2  =  time  of  flight  greater  than  maximum  time  of  flight  (tmax  =  80  sec) 

3  =  Mach  number  less  than  min  Mach  number 

4  =  Mach  number  greater  than  max  Mach  number 

5  =  closure  speed  less  than  min  closure  speed 

6  =  maximum  acceleration  dropped  below  „bmaxgr“  at  range  less  than  rbmax 

7  =  seeker  head  had  „lock  on11,  yet  range  increased  to  1 .4  of  lock  range 

8  =  seeker  head  can  not  establish  „lock  on11 
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9  =  Line  of  Sight  (LOS)  to  target  lost  (due  to  terrain)  after  „lock  on“ 

13  =  missile  hit  ground 

- 1  =  look  angle  exceeded 

-2  =  LOS  rate  exceeded  after  „lock  on“ 

-4  =  target  disappeared 

Short  Range  Missile 

0  =  normal  flight 

1  =  time  of  flight  less  than  minimum  time  for  warhead  activation 

2  =  time  of  flight  greater  than  maximum  time  of  flight  (tmax  =  50  sec) 

3  =  dynamic  pressure  q  less  than  qmin  after  boost  phase 

4  =  dynamic  pressure  q  greater  than  qmax 

5  =  closure  speed  less  than  0.  after  boost  phase 
- 1  =  look  angle  exceeded 
-2  =  LOS  rate  exceeded 
-3  =  Infra  Red  (IR)  seeker  lost  „lock  on“ 

(reasons  can  be  : 

•  IR  emissions  of  target  decreased 

•  target  disappeared 

•  missile  diverted  by  flares) 

Symbol 

DASA  Dome  Cockpit 
Neutral  DASA  Dome  Cockpit 

DASA  VLO  Cockpit  /  Wright  Lab  Cockpit  ("own  force") 

CGT  ("own  force") 

DASA  VLO  Cockpit  /  Wright  Lab  Cockpit  ("foe") 

Neutral  DASA  VLO  Cockpit 
Red  CGT  ( free  fighter  or  detached  escort ) 

Red  CGT  (dose  escort) 

Red  CGT  ( fighter  bomber ) 

Neutral  CGT 
Medium  Range  Missile 
Short  Range  Missile 
Chaff  Drop 
Flare  Drop 
Missile  Kill 

Fig.  12-1  Plot  Legend 
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12.2  Evaluation  of  Scenario  S3  Runs 

In  this  scenario  the  „blue  forces"  perform  a  „scramble  takeoff1  from  Williams  Airforce  Base.  The  „red  forces" 
start  at  a  point  located  about  72  nm  east  (077)  in  an  altitude  of  15000  ft,  Ma  =  0.67  and  a  heading  of  290 
degrees. 

Each  aircraft  carries  4  MRM,  4  SRM  and  30  flares. 

•  Air  Force  Research  Laborator  cockpits  are  “blue  side" 

(run  2  on  Mon  Oct  27  14:25:27  1997,  Fig.  12-2  to  Fig.  12-4and  a  „blow  up"  plot  in  Fig.  12-5  and  Fig.  12-6, 
Fig.  12-7  and  Fig.  12-8) 

Both  blue  aircraft  turn  to  heading  270  after  take  off.  They  make  advantage  of  their  superior  aircraft  performance 
and  radar  sensor  capability.  They  turn  back  to  heading  090  after  having  reached  about  50000  ft  and  Ma  =  1.72, 
resp.  43000  ft  and  Ma  =  2.16. 

Blue  2  fires  his  first  MRM  on  Red  2  at  t  =  177  sec  (Ma  =  2.35,  h  =  40  kft,  r  =  100  km  -  that  means  he  has  Jock 
on“  at  that  range).  He  fires  his  second  MRM  on  Red  1  at  t  =  199  sec  (Ma  =  2.50,  h  =  40  kft,  range  =  97  km). 

Red  1  achieves  radar  Jock  on"  at  t  =  230  sec  (ca.  70  km  =  38  nm,  maximum  Jock  on"  range  of  DASA  radar  in 
TWS  and  MPRF-PK  is  somewhat  less  than  40  nm). 

Red  1  fires  his  MRM  at  t  =  236  sec  (Ma  =  1 .34,  h  =  5 1  kft,  r  =  65  km). 

At  that  moment,  the  MRM  of  Blue  2  has  a  range  of  37  km  and  a  closure  rate  of  1550  m/sec  to  Red  1. 

At  t  =  255  sec.  Red  1  gets  a  missile  warning  (MRM  at  Ma  =  3.50  and  closure  rate  still  1 120  m/sec).  Red  l’s 
missile  avoidance  maneuver  can  not  outrun  the  missile  anymore  (hit  at  t  =  267  sec,  see  figure  7  and  8).  At  that 
time  Red  l’s  missile  range  to  Blue  2  is  about  36  km  (Ma  =  3.7  and  vcl  =  1 190  m/sec),  therefore  requiring  at 
least  another  25  sec  for  guidance  update  which  was  no  more  possible. 

While  Red  1  was  attacking  high,  Red  2  was  descending  to  very  low  altitude,  trying  to  hide  in  the  terrain  (with 
radar  off  -  no  electronic  emissions  !  -  and  maintaining  a  mean  terrain  clearance  of  less  than  600  ft).  Around  t  = 
220  sec  he  was  also  flying  a  „beam  maneuver"  against  the  attacking  two  blue  aircraft,  trying  to  use  the  well 
known  „Doppler  notch"  phenomenon,  characteristically  for  Pulse  Doppler  radars  to  deny  radar  lock.  However, 
the  radar  lock  of  blue  aircraft  could  obviously  not  be  broken.  Finally,  after  popping  up  at  around  t  =  280  sec,  a 
mutual  kill  occurred  between  Blue  2  and  Red  2. 


Summary  of  outcome  : 

Blue  1  : 

no  target  hits 
survives  engagement 

Blue  2  : 

hits  Red  1  at  t  =  267  sec 

hits  Red  2  at  t  =  3 13  sec 
hit  by  Red  2  at  t  =  3 17  sec 
and  at  t  =  319  sec 

and  at  t  =  324  sec 

Red  1  : 

no  target  hits 

hit  by  Blue  2  at  t  =  267  sec 

Red  2  : 

hits  Blue  2  at  t  =  3 17  sec 

and  at  t=  319  sec 

and  at  t  =  324  sec 

hit  by  Blue  2  at  t  =  3 13  sec 
•  DASA  cockpits  are  „blue  side" 

(run  3  on  Mon  Oct  27  14:25:27  1997,  Fig.  12-9  to  Fig.  12-1  land  a  „blow  up"  plot  in  Fig.  12-12  and  Fig.  12- 
13) 
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Blue  aircraft  split  at  about  t  =  100  sec  (Blue  1  continuing  westerly  heading,  Blue  2  turning  towards  red  aircraft). 
Red  2  disengages  from  fight  at  about  t  =  220  sec,  after  having  fired  two  MRM’s. 

Red  1  engages  blue  aircraft  gi ving  another  example  of  his  powerful  performance,  starting  a  climb  (t  =  240  sec) 
at 

h  =  9400  m  with  Ma  =  2.20  and  climbing  up  to  16400  m  within  20  sec  (mean  climb  speed  of  350  m/sec,  which 
is  about  70000  ft/min,  at  Ma  =  2.05;  more  than  Ma  =  1.0  climb  speed  !;  mean  climb  angle  of  40  degrees). 

Red  1  fires  his  first  missile  at  t  =  210  sec  (which  never  reaches  autonomous  status)  and  his  second  missile  at 
t  =  267  sec  in  h  =  18700  m  at  Ma  =  1.60  and  a  climb  angle  of  about  30  degrees.  This  MRM  hits  Blue  1  at 
t  =  329  sec. 

Red  1  continues  his  climb  up  to  20200  m,  ending  up  with  Ma  0  0.85,  a  very  „bad“  situation  to  outrun  a  MRM. 
Blue  2’s  first  MRM  (fired  at  t  =  290  sec)  hits  Red  1  at  t  =  322  sec.  About  10  sec  later  Blue  l’s  MRM  (fired  at 
t  =  277  sec)  hits  Red  1.  A  SRM  fired  by  Red  1  at  t  =  316  sec  can  be  defeated  by  Blue  2  through  his  use  of  flares. 

Red  1,  unaffected  by  two  missile  hits,  disengages  from  the  fight.  After  having  been  hit  again  by  the  second 
MRM  of  Blue  2,  he  obviously  accepts  the  kill  and  falls  down.  The  third  missile  of  Blue  2  is  terminated  because 
it  loses  target  lock,  as  Red  1  is  plunging  into  terrain. 


Summary  of  outcome : 


Blue  1  :  hits  Red  1  at  t  =  332  sec 

hit  by  Red  1  at  t  =  329  sec 

Blue  2  :  hits  Red  1  at  t  =  322  sec 

and  at  t  =  428  sec 
survives  engagement 

Red  1  :  hits  Blue  1  at  t  =  329  sec 

hit  by  Blue  2  at  t  =  322  sec 
and  at  t  =  428  sec 

Red  2  :  no  target  hits 

survives  engagement 


•  DAS  A  cockpits  are  „blue  side" 

(run  1  on  Mon  Oct  27  14:56:13  1997,  Fig.  12-14  toFig.  12-16  and  a  „blow  up“  plot  in  Fig.  12-17 andFig. 
12-18;  extract  from  t  =  240  to  321  sec  in  Fig.  12-19  and  Fig.  12-20) 

The  early  firings  of  Red  1  and  Red  2  (two  firings  each)  result  in  clear  misses,  since  both  blue  aircraft  turned 
away  (at  t  =  120  sec),  yet  without  having  fired  own  missiles. 

Also  the  next  two  MRM’s  fired  by  Red  1  (at  t  =  153  sec  and  t  =  160  sec)  miss  their  targets.  Red  1  has  no  more 
MRM’s  and  presses  on  into  short  range  engagement. 

Meanwhile,  Red  2  made  advantage  of  his  aircraft  performance  and  reached  Ma  =  2.51  in  h  =  12600  m. 

What  comes  now  is  an  example  of  the  superior  radar  sensor  system.  Red  2  accomplishes  to  fire  his  remaining 
two  MRM’s  on  to  Blue  1  and  Blue  2  within  3  seconds  (t  =  248  sec  and  t  =  251  sec,  see  figures  19  and  20). 
Although,  the  blue  aircraft  are  about  75  degrees  apart.  Red  2  manages  to  have  „lock  on"  on  both  targets  (or  at 
least  is  able  to  switch  locks  that  fast),  designate  and  fire  on  to  both  aircraft  within  3  seconds. 

Both  blue  aircraft  had  engaged  the  „etemal  life"  switch  and  therefore  continue  the  engagement,  Blue  2  defeats 
Red  l’s  SRM  by  deploying  flares  and  hits  Red  2  with  a  MRM  at  t  =  351  sec.  Blue  1  hits  Red  2  with  3  MRM’s  at 
t  =  348,  349  and  352  sec. 

No  outcome  summary  „life  switch"  pressed. 
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Fig.  12-2  R2  -  Trajectory  plot  (Z-Y  -  Axis)  Fig.  12-3  R2  -Trajectory  plot  (X-Y  -  Axis) 
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Fig.  12-4  R2  -  Summary  Table 
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Fig.  12-5  R2  -  Trajectory  plot  (Z-Y  -  Axis,  Fig.  12-6  R2  -  Trajectory  plot  (X-Y  -  Axis,  „BIow  Up“) 

„Blow  Up“) 
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Fig.  12-8  R2  -  Trajectory  plot  (Z-Y  -  Axis,  „Blow  Fig.  12-7  R2  -  Trajectory  plot  (X-Y  -  Axis,  „Rlow  Up“) 
Up“) 
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Fig.  12-10  R3  -  Trajectory  plot  (Z-Y  -  Axis) 


Fig.  12-9  R3  -  Trajectory  plot  (X-Y  -  Axis) 
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Fig.  12-11  R3  -  Summary  Table  Run3 
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Fig.  12-15  R1  -  Trajectory  plot  (Z-Y  -  Axis)  Fig.  12-14  R1  -  Trajectory  plot  (X-Y  -  Axis) 
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Fig.  12-16  R1  -  Summary  Table 
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Fig.  12-17  R1  -  Trajectory  plot  (Z-Y  -  Fig.  12-18  R1  -  Trajectory  plot  (X-Y  -  Axis,  „BIow  Up“) 

Axis,  „BIow  Up“) 
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12.00 


Fig.  12-20  R1  -  Trajectory  plot  (Z-Y  -  Axis,  Fig.  12-19  R1  -  Trajectory  plot  (X-Y  -  Axis,  „Blow  Up“) 

„Blow  Up“) 
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12,3  Evaluation  of  Scenario  S5  Runs  (Joint  Mission  Training) 

Air  Force  Research  Laboratory  and  DASA  cockpits,  on  “blue  side“,  start  “line  abreast“  in  15000  ft  at  Ma  =  0.67 
with  heading  090  (spacing  between  fighters  :  Blue  1  -  Blue  2  =  2000  m.  Blue  2  -  Blue  3  =  2400  m.  Blue  3  -  Blue 
4  =  2200  m). 

Three  CGT’s  in  the  role  of  ^detached  escorts“  start  about  80  nm  east  of  the  cockpits  in  10000  ft  at  Ma  =  0.66 
and  a  heading  of  268. 

All  fighters  -  cockpits  or  CGT  -  are  equipped  with  4  MRM,  4  SRM  and  30  flares. 

A  further  CGT  in  the  role  of  „fighter  bomber“  starts  in  4300  ft  at  Ma  =  0.64  with  a  heading  of  308. 

The  escorts  maintain  speed  and  altitude  while  heading  for  a  waypoint  located  at  the  „Forward  Line  of  Troops“ 
(PLOT).  After  crossing  the  FLOT,  they  switch  on  their  radars  and  initiate  the  engagement.  If  not  destroyed,  the 
engagement  is  ended  when  their  remaining  fuel  reaches  a  predefined  value.  They  will  then  disengage  and  return 
to  their  ingress  corridor. 

The  bomber  descends  to  low  altitude,  initiating  „terrain  following",  trying  to  maintain  a  terrain  clearance  of  80 
m.  It  follows  a  preprogrammed  waypoint  route  (mission  goal  is  to  unload  bombs  on  Nellis  airbase)  and  returns 
to  home  base  after  mission  completion. 

Defensive  maneuver  is  a  „Doppler  notch"  maneuver  when  tracked  from  the  front  hemisphere.  It  reacquires  its 
waypoint  route  if  unthreatened  or  tracked  from  the  back  hemisphere.  Weapons  carried  are  4  SRM  which  will  be 
employed  if  chances  for  opponent  kill  is  high  (it  will  then  switch  on  its  radar  and  fire  on  opponent;  return  to 
mission  if  Short  Range  engagement  is  finished).  In  case  a  missile  (MRM  or  SRM)  is  fired  on  it,  bombs  will  be 
dropped  and  an  avoidance  maneuver  is  performed.  If  missile  is  successfully  avoided,  the  bomber  will  disengage 
and  return  to  home  base. 

•  Run  of  Wed  Oct  29  13:47:35  1997 

(Fig.  12-21  to  Fig.  12-24;  „blow  up“  plots  in  Fig.  12-25  Fig.  12-30) 


Summary  of  outcome : 

Blue  1  : 

hits  bomber  at  t  =  474  sec 
survives  engagement 

Blue  2 : 

hits  Red  2  at  t  =  345  sec 

hit  by  Red  2  at  t  =  371  sec  ->  „mutual  kill" 

barely  missed  by  Red  1  at  t  =  379  sec  while  crashing 

Blue  3 : 

hits  Red  3  at  t  =  678  sec 
survives  engagement 

Blue  4 : 

hit  by  Red  3  at  t  =  3 14  sec 

Red  1  : 

no  target  hits 
survives  engagement 

Red  2  : 

hit  by  Blue  2  at  t  =  345  sec 

hit  Blue  2  at  t  =  371  sec  --->  „mutual  kill" 

Red  3  : 

hit  Blue  4  at  t  =  3 14  sec 
hit  by  Blue  3  at  t  =  678  sec 

Red  4  : 

hit  by  Blue  1  at  t  =  474  sec 
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•  Run  of  Wed  Oct  29  14:13:25  1997 

(Fig.  12-31  to  Fig.  12-34;  „blow  up“  plots  in  Fig.  12-35  and  Fig.  12-36) 

Summary  of  outcome : 


Blue  1  : 

no  target  hits 
survives  engagement 

Blue  2 : 

hits  Red  1  at  t  =  422  sec 
hits  Red  2  at  t  =  425  sec 
hits  Red  4  at  t  =  421  sec 
survives  engagement 

Blue  3  : 

hits  Red  3  at  t  =  365  sec 
survives  engagement 

Blue  4 : 

no  target  hits 
survives  engagement 

Red  1  : 

no  target  hits 

hit  by  Blue2  at  t  =  422  sec 

Red  2  : 

no  target  his 

hit  by  Blue2  at  t  =  425  sec 

Red  3  : 

no  target  his 

hit  by  Blue3  at  t  =  422  sec 

Red  4  : 

no  target  his 

hit  by  Blue2  at  t  =  421  sec 

•  Run  of  Wed  Oct  29  15:08:51  1997 

(Fig.  12-37  to  Fig.  12-40;  „blow  up“  plots  in  Fig.  12-41  to  Fig.  12-45) 


Summary  of  outcome  : 

Blue  1  : 

hits  Red  2  at  t  =  432  sec  with  SRM 

defeats  SRM  of  Red  2  at  t  =  432  sec  through  use  of  flares 

hit  by  Red  1  at  t  =  45 1  sec 

Blue  2  : 

hits  Red  4  at  t  =  292  sec 
survives  engagement 

Blue  3  : 

no  target  hits 
survives  engagement 

Blue  4  : 

hits  Red  3  at  t  =  478  sec 
hit  by  Red  1  at  t  =  469  sec 

Red  1  : 

hits  Blue  1  at  t  =  45 1  sec 
hits  Blue  4  at  t  =  469  sec 

Red  2  : 

no  target  hits 

hit  by  Blue  1  at  t  =  432  sec  with  SRM 

Red  3  : 

no  target  hits 

hit  by  Blue  4  at  t  =  478  sec 

Red  4  : 

hit  by  Blue  2  at  t  =  292  sec 
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Fig.  12-21  R1  -  Trajectory  Plot  (Z-Y  Axis)  Fig.  12.22  R1 .  Trajectory  Plot  (X-Y  Axis) 
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Fig.  12-23  R1  -  Summary  Table 
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Fig.  12-28  R1  -  Trajectory  Plot  (X-Y  Axis,  „Blow  Up“) 


12-23 


0.00  5.00  10.00  15.00  20.00  25.00  30.00  35.00  40.00  45.00  50.00  55.00 

Name  :  Operational  Pilot  Y-Axis  [km]  Wed  Oct  29  13:47:35  1997 


12-24 


Transatlantic  Research  into  Air  Combat  Engagements  Final  Report 

Doc. -No.:  Dasa-S-R- 1775-02  12.  Appendix  D  -  Selected  Data  Recorded  During  Production  Runs 


Fig.  12-30  R1  -  Trajectory  Plot  (X-Y  Axis, “Blow  Up“) 
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Fig.  12-31  R2  -  Trajectory  Plot  (Z-Y  Axis) 


Fig.  12-32  R2  -  Trajectory  Plot  (X-Y  Axis) 
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Fig.  12-33  R2  -  Summary  Table 


Fig.  12-34  R2.-.  Summary  Table  (cont) 


Fig.  12-35  R2  -  Trajectory  Plot  (Z-Y  Axis, “Blow  Up“) 
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Fig.  12-36  R2  -  Trajectory  Plot  (X-Y  Axis,“Blow  Up“) 
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Fig.  12-39  R3  -  Summary  Table 


Fig.  12-40  R3  -  Summary  Table  (cont) 
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Fig.  12-41  R3  -  Trajectory  Plot  (Z-Y  Axis, “Blow  Up“) 
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Fig.  12-42  R3  -  Trajectory  Plot  (X-Y  Axis, “Blow  Up“) 
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Fig.  12-43  R3  -  Trajectory  Plot  (X-Y  Axis,“Blow  Up“) 
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Fig.  12-44  R3  -  Trajectory  Plot  (Z-Y  Axis, “Blow  Up“) 
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Fig.  12-45  R3  -  Trajectory  Plot  (X-Y  Axis,“Blow  Up“) 
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13.  Appendix  E  Methods  for  Dasa-NIC-Interface  Access  IDasal 

13.1  Methods  for  filling  data  in  Entity.  iCommand.  iData.  iRadar,  iJammer  objects. 

To  fill  an  iEntity  object  with  data  the  following  methods  are  available: 

void  wtime_stamp  (float64  time_stamp);  //  seconds  of  current  hour 
void  wAbsTimeStamp(  uint8  flag);  //  true  =  absolute  time  stamp 
void  wEntity_ID(  EntitylD  &); 

void  wEntity_ID(  uint16  site,  uintl 6  application,  uint16  entity): 
void  wEntity_Type(  EntityType  &); 

void  wEntity_Type(  uint8  kind,  uint8  domain,  uintl  6  country, 

uint8  cat,  uint8  subcat,  uint8  spec,  uint8  extra); 
void  wEntity_Type(  uint8  EntityTypeFormat,  int32  entity_type); 
void  wDRAIgorithmf  uint8  DRAIgorithm); 

void  wLocation(  Position_3D  &Location,  int  CoordinateSystemID,  int  Unitld); 

void  wOrientation(  Orientation_Data  &Orientation,  int  Orientationld); 

void  wLinear_Vel(  Vector_3D  &  Linear_Vel,  int  CoordinateSystemID,  int  Unitld); 

void  wLinear_Acc(  Vector_3D  &  Linear_Acc,  int  CoordinateSystemID,  int  Unitld); 

void  wAngular_Vel(  Vector_3D  &  Angular_Vel); 

void  wAngular_Acc(  Vector_3D  &  Angular_Acc); 

void  wEntityAppearance(  uint32  EntityAppearance); 

void  wForce_ID(  uint8  ForceJD); 

void  wRole(  uint8  Role); 

void  wnShortRangeMissiles(  uint8  numberShortRangeMissiles); 

void  wnMediumRangeMissiles(  uint8  numberMediumRangeMissiles); 

void  wMissileNumber(  uint8  MissileNumber); 

void  wPower(  uint8  Power); 

void  wFuelFlow(  uintl  6  FuelFlow); 
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void  wMissileStatus(  uint8  MissileStatus); 

void  wMissileBreakC(  uint8  MissileBreakCondition); 

void  wEntityActive(  uint8  flag);  //  true  =  active 

void  wMannedCockpit(  uint8  flag);  //  true  =  manned 

void  wGearState(  uint8  flag);  //  true  =  gear  down 

void  wAfterburner(  uint8  flag);  //  true  =  afterburner  on 

void  wLauncher(  EntitylD  &Launcher); 

void  wT arget(  Entityl  D  &T arget) ; 

void  wFlare(  Flare_Data  &); 

void  wChaff(  Chaff_Data  &); 


General  methods  available  for  an  iEntitv  object: 
char*  PrintData(  char*  text);  //  prints  contents  of  iEntity  object 
BOOLEAN  Aircraft();  //  returns  TRUE  if  entity  is  an  aircraft 

BOOLEAN  Missile();  //  returns  TRUE  if  entity  is  a  missile 

BOOLEAN  AircraftMissile();  //  returns  TRUE  if  entity  is  an  AC  or  missile 

BOOLEAN  Flare();  //  returns  TRUE  if  entity  is  a  flare 

BOOLEAN  Chaff();  //  returns  TRUE  if  entity  is  a  chaff 

BOOLEAN  FlareChaff();  //  returns  TRUE  if  entity  is  flare  or  chaff 


NOTES: 

'wLocation'  writes '  Location  '  into  internal  representation.  The  Coordinate  System 
of  '  Location '  is '  CoordinateSystemID  ’  and  the  Unit  is  'Unitld'. 
'wOrientation'  writes 1  Orientation '  into  internal  representation.  The  representation 
of '  Orientation  1  is  according  to  ’Orientationld'. 
typedef  enum 
{ 

FLAT_EARTH_NED,  //  xNorth  yEast  zDown 

WGS_84,  //  WorldCoordinateSystem  WGS  84 
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FLAT_EARTH_NEU,  //xNorth  yEast  zUp 

FLAT_EARTH_ENU,  //xEast  yNorth  zUp 

LATLONALT  //  xLatitude,  yLongitude,  zAltitude 

}  CoordinateSystemID; 

typedef  enum 

{ 

METER, 

FEET 
}  Unitld; 

typedef  enum 

{ 

QUATERNIONS, 

EULER_ANGLES 
}  OrientationID; 

typedef  enum 

{ 

Dasa, 

WL 

}  EntityTypeFormat; 

typedef  enum 

{ 

EFA_TYPE  =  1, 

F15E_TYPE  =  55, 

SAMJHAWK_AFU  =101, 

SAM_IHAWK_SQN_PIP2  =  102, 

SAM_IHAWK_SQN_PIP3  =  103, 


//  METER/SEC  ,  METER/SEC2  respectively 
//  FEET/SEC  ,  FEET/SEC2  respectively 


//  P0=q0,  P1=q1,  P2=q2,  P3=q3 

//P0=psi,  P1=theta,  P2=phi 


13-3 


Transatlantic  research  into  Air  Combat  Engagements  Final  Report 


Doc.-No.:  Dasa-S-R- 1775-02  13.  Appendix  E  Methods  for  Dasa-NIC-Interface  Access 

SAM_PATRIOT  =  105, 

SAM_TLVS  =110, 

RADARSITE_TYPE  =  200, 

CRC_LOCAL  =  201, 

CRC_GRND_REMOTE  =  202, 

CRC_AIR_REMOTE  =  203, 

AAM_MISSILE_TVPE  =  1000, 

MR_MISSILE_TYPE  =1001, 

SR_MISSILE_TYPE  =  1002, 


SAM_HAWK_M3_M  I  SSI  LE_TYPE  =1101, 

SAM_PATRI  OT_P  AC2_M  ISS I  LE_TYPE  =1102, 
SAM_PATRIOT_PAC3_MISSILE_TYPE  =1103, 
SAM_TLVS_M  I SS I  LE_TYPE  =1120, 


FLARE_TYPE 

=  2000, 

CHAFF_TYPE 

=  3000, 

SIF_TYPE 

=  4000, 

BOMB_TYPE 

=  5000, 

}  DasaEntityTypes; 


To  fill  an  iCommand  object  with  data  the  following  methods  are  available: 
void  wSender_ID(  EntitylD  &  entityjd); 
void  wSender_ID(  uint16  site,  uint16  application,  uint16  entity); 
void  wReceiver_ID(  EntitylD  &  entityjd); 
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void  wReceiver_ID(  uint16  site,  uintl  6  application,  uint16  entity); 

void  wCommand(  uint8  Command); 

void  wEffectTime(  float64  EffectTime);  //  seconds  of  current  hour 


General  methods  available  for  iCommand  object: 

char*  PrintData(  char*  text);  //  prints  contents  of  iCommand  object 


NOTES: 
typedef  enum 
{ 

Cmd_SM  JNIT,  //  commands  from  Scenario  Manager 

Cmd_SM_EXECUTE, 

Cmd_SM_FREEZE, 

Cmd_SM_TERMINATION, 

Cmd_SM_REINIT, 

Cmd_SM_RELEASE, 

CmdJNIT, 

Cmd.RUN, 

CmdJHOLD, 

Cmd_END, 

Cmd_SEND_INIT_DATA  =  20  //  send  your  init  data  to  controller 

}  CommandPduCommands; 


To  fill  an  iData  object  with  data  the  following  methods  are  available; 
void  wSender_ID(  EntitylD  &  entityjd); 
void  wSender_ID(  uintl  6  site,  uintl  6  application,  uintl  6  entity); 
void  wReceiver_ID(  EntitylD  &  entityjd); 
void  wReceiverJD(  uintl  6  site,  uintl  6  application,  uintl  6  entity); 
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void  wCommand(  uint8  Command); 

// - 

//  write  <NumDataBytes>  Data  Bytes  from  <p_theData>  adress 
//  into  iData  object  Data  area 

// - 

BOOLEAN  wData(  void  *p_theData,  uint16  NumDataBytes); 
void  wDataType(  uint32  dataType); 

General  methods  available  for  iData  object: 

char*  PrintData(  char*  text);  //  prints  contents  of  iData  object 

To  fill  an  iRadar  object  with  data  the  following  methods  are  available: 
void  wSender_ID(  EntitylD  &  entityjd); 
void  wSenderJD(  uint16  site,  uintl  6  application,  uint16  entity); 
void  wReceiver_ID(  EntitylD  &  entityjd); 
void  wReceiverJD(  uintl  6  site,  uintl  6  application,  uintl  6  entity); 


uintl  6 

uintl  6 

float32 

RadarMode; 

RadarType; 

frequency; 

//MHz 

float32 

beamDirection; 

//  radian 

float32 

beamElevation; 

//  radian 

float32 

beamStrength; 

//  dB 

General  methods  available  for  iRadar  object: 

char*  PrintData(  char*  text);  //  prints  contents  of  iRadar  object 


NOTES: 
typedef  enum 
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{ 


cw, 

PDOP, 

IHAWKJPAR  =  11, 

IHAWKJCWAR, 

IHAWKJHIPIR, 

PATRIOT.RS, 

TLVS.RS 

}  DasaRadarTypes; 


typedef  enum 

{ 

SURVEILLANCE  =1, 
TRACKING, 
TERMINAL_PHASE 
}  DasaRadarModes; 


To  fill  an  iJammer  object  with  data  the  following  methods  are  available: 
void  wSender_ID(  EntitylD  &  entityjd); 
void  wSender_ID(  uint16  site,  uint16  application,  uint16  entity); 
void  wReceiver_ID(  EntitylD  &  entityjd); 
void  wReceiverJD(  uint16  site,  uintl  6  application,  uint16  entity); 
uint16  JammerMode; 
uintl  6  JammerType; 
float32  frequency;  //MHz 

float32  headingToJammer;  //radian 
float32  elevationToJammer;  //  radian 
float32  signalStrength;  //  dB 
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General  methods  available  for  iJammer  object: 

char*  PrintData(  char*  text);  //  prints  contents  of  iJammer  object 

13.2  Methods  for  retrieving  data  from  Entity,  iCommand,  iData,  iRadar,  iJammer 
objects. 

To  retrieve  the  data  from  an  iEntity  object  the  following  methods  are  available: 


float64 

rtime_stamp  ()  const; 

uint8 

rAbsTimeStampO  const; 

const  Entity  ID 

&rEntity_ID()  const; 

u  inti  6 

rEntityNumber()  const; 

uintl  6 

rApplicationNumber()  const; 

uint16 

rSiteNumber()  const; 

const  EntityType 

&rEntity_Type()  const; 

int32 

rEntity_Type(  uint8  EntityTypeFormat)  const; 

uint8 

rDRAIgorithm()  const; 

Position_3D 

rLocation(  int  CoordinateSystemID,  int  Unitld)  const; 

Orientation_Data 

rOrientation(  int  Orientation  Id)  const; 

uint8 

rOrientatld()  const; 

Vector_3D 

rLinear_Vel(  int  CoordinateSystemID,  int  Unitld)  const; 

Vector_3D 

rLinear_Acc(  int  CoordinateSystemID,  int  Unitld)  const; 

Vector_3D 

rAngular_Vel()  const; 

Vector_3D 

rAngular_Acc()  const; 

uint32 

rEntityAppearance()  const; 

uint8 

rForce_ID()  const; 

uint8 

rRole()  const; 

uint8 

rnShortRangeMissiles()  const; 

uint8 

mMediumRangeMissiles()  const; 

uint8 

rMissileNumber()  const; 
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uint8 

rPower()  const; 

uint16 

rFuelFlow()  const; 

uint8 

rMissileStatus()  const; 

uint8 

rMissileBreakC()  const; 

uint8 

rEntityActive()  const; 

uint8 

rMannedCockpit()  const; 

uint8 

rGearState()  const; 

uint8 

rAfterburner()  const; 

const  EntitylD 

&rLauncher()  const; 

const  EntitylD 

&rTarget()  const; 

Flare_Data 

rFlare()  const; 

Chaff_Data 

rChaff()  const; 

NOTES: 

'  rLocation  '  reads  Entity  Location  and  converts  it  according  to 
'  CoordinateSystemID  '  and  '  Unitld 
'  rOrientation  '  reads  Entity  Orientation  and  converts  it  according  to 
1  OrientationID 


To  retrieve  the  data  from  an  iCommand  object  the  following  methods  are  available: 
const  Entity  ID  &rSender_ID()  const; 

const  Entity  ID  &rReceiver_ID()  const; 

uint8  rCommandO  const; 
float64  rEffectTimeO  const; 

To  retrieve  the  data  from  an  iData  object  the  following  methods  are  available: 
const  EntitylD  &rSender_ID()  const; 
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const  EntityiD  &rReceiver_ID()  const; 
uint8  rCommand()  const; 

// - - 

//  read  <NumDataBytes>  Data  Bytes  from  iData  object  and 

//  copy  them  into  <p_theData>  adress 

// - 

BOOLEAN  rData(  void  *p_theData,  uint16  NumDataBytes); 

uint32  rDataType(  void)  const; 

To  retrieve  the  data  from  an  iRadar  object  the  following  methods  are  available: 
const  EntityiD  &rSender_ID()  const; 

const  EntityiD  &rReceiver_ID()  const; 

uintl  6  RadarMode; 
uint16  RadarType; 
float32  frequency;  //  MHz 

float32  beamDirection;  //  radian 
float32  beamElevation;  //  radian 
float32  beamStrength;  //  dB 

To  retrieve  the  data  from  an  iJammer  object  the  following  methods  are  available: 
const  EntityiD  &rSender_ID()  const; 

const  EntityiD  &rReceiver_ID()  const; 

uintl  6  JammerMode; 
uintl  6  JammerType; 
float32  frequency;  //MHz 

float32  headingTo Jammer;  //  radian 
float32  elevationToJammer;  //  radian 
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float32  signal  Strength;  //  dB 
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